> 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).