-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
DEP: deprecate empty field names #12375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Labels please. |
ac066e2
to
657db88
Compare
should hit the mailing list |
657db88
to
eaca685
Compare
If it needs to hit the mailing list, please do so. |
Hmm. The problem is deeper than just blank names. >>>a = np.dtype({'names': ['a', 'b'], 'formats': ['i4'] * 2, 'offsets': [0, 2]})
>>>a.descr
[('a', '<i4'), ('b', '<i4')] # loses the offsets :(
>>>str(a)
"{'names':['a','b'], 'formats':['<i4','<i4'], 'offsets':[0,2], 'itemsize':6}" Maybe we should abandon deprecating blank fields, as it does not solve the roundtrip save/load problem. We could try using |
On 1.15 (since #10391) your code gives an error,
|
Counterexample: Can't we just pickle the dtype? |
Also, that's similar to the overlapping-fields problem in the PEP3118 interface, see this comment. It turns out that the PEP3118 structure format string cannot represent overlapping or out-of-order fields. Since In my opinion, the "best" ultimate behavior would be for us to work with CPython to update or extend the PEP3118 format string for structs so it can handle overlapping fields, out-of-order-fields, and padding, using the justification in the linked comment above. Then deprecate |
|
It's not clear to me why the buffer interface and a serialization format need to be related. It's not unreasonable for numpy to support custom or third-party dtypes that are not part of PEP3118, and we need to be able to save those too. Python already has a serialization protocol - pickle. Why can't we just use it? What makes it worth defining a custom serialization format for the data type?
The word "serial" appears nowhere in PEP3118. PEP3118 is a memory sharing interface, not a serialization interface. |
Well, I suppose that's true, that seems like a reasonable solution as well. We've already written all the pickle serialization stuff in My background thought, though, was it would be "cool" if |
@mattip Abandon? |
Split off from PR #12358. Empty field names are confusing, users should construct record arrays with name, format, offset dictionaries instead.