This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients Alexander.Belopolsky, MrJean1, ajaksu2, barry, benjamin.peterson, inducer, mark.dickinson, meador.inge, noufal, pitrou, pv, teoliphant
Date 2010-12-03.08:36:30
SpamBayes Score 2.37738e-10
Marked as misclassified No
Message-id <>
> For reference, Numpy's PEP 3118 implementation is here:

Thanks for that, and the other information you give;  that's helpful.

It sounds like we're on the same page with respect to alignment of substructs.  (Bar the mostly academic question of max versus lcm.)

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.

- I assumed the 'O' format in the PEP is supposed to be similar to Numpy
  object arrays. This implies some reference counting semantics. The
  Numpy PEP 3118 implementation assumes the memory contains borrowed
  references, valid at least until the buffer is released.
  Unpacking 'O' should probably INCREF whatever PyObject* pointer is

I'm still confused about how this could work:  when unpacking, how do you know whether the PyObject* pointer points to a valid object or not?  You can ensure that the pointer will always point to a valid object by having the *pack* operation increment reference counts, but then you need a way to automatically decref when the packed string goes out of scope.  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.

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?
Date User Action Args
2010-12-03 08:36:34mark.dickinsonsetrecipients: + mark.dickinson, barry, teoliphant, pitrou, inducer, ajaksu2, MrJean1, benjamin.peterson, pv, noufal, meador.inge, Alexander.Belopolsky
2010-12-03 08:36:34mark.dickinsonsetmessageid: <>
2010-12-03 08:36:31mark.dickinsonlinkissue3132 messages
2010-12-03 08:36:30mark.dickinsoncreate