Pauli Virtanen <p...@iki.fi> added the comment:
> I still like the idea of scoped endianness markers in the substructs,
> but if we have to abandon that for compatibility with NumPy that's
> okay.
That, or change the Numpy implementation. I don't believe there's yet much code
in the wild that changes the alignment specifier on the fly.
[clip: 'O' format code]
> So the object returned by 'pack' would somehow
> have to be something other than a plain string, so that it can deal
> with automatically doing the DECREF of the held PyObject* pointers
> when it goes out of scope.
Yes, the packed object would need to own the references, and it would be the
responsibility of the provider of the buffer to ensure that the pointers are
valid.
It seems that it's not possible for the `struct` module to correctly implement
packing for the 'O' format. Unpacking could be possible, though (but then if
you don't have packing, how write tests for it?).
Another possibility is to implement the 'O' format unsafely and leave managing
the reference counting to whoever uses the `struct` module's capabilities. (And
maybe return ctypes pointers on unpacking.)
[clip]
> What's the need to have the 'O' format in the struct module? Is it
> really necessary there? Can we get away with not implementing it?
Numpy arrays, when containing Python objects, function as per the 'O' format.
However, for the struct module, I don't see what would be the use case for the
'O' format.
> BTW, does this already exist in a released version of NumPy? If not,
> when is it likely to appear in the wild?
It's included since the 1.5.0 release which came out last July.
***
I think after the implementation is done, the PEP probably needs to be amended
with clarifications (and possibly cutting out what is not really needed).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
