[Python-Dev] idea for data-type (data-format) PEP

["Martin v. Löwis"]

Travis E. Oliphant schrieb:
> What if we look at this from the angle of trying to communicate 
> data-formats between different libraries (not change the way anybody 
> internally deals with data-formats).

ISTM that this is not the right approach. If the purpose of the datatype
object is just to communicate the layout in the extended buffer
interface, then it should be specified in that PEP, rather than being
stand-alone, and it should not pretend to serve any other purpose.
Or, if it does have uses independent of the buffer extension: what
are those uses?

> 1) We could define a special string-syntax (or list syntax) that covers 
> every special case.  The array interface specification goes this 
> direction and it requires no new Python types.  This could also be seen 
> as an extension of the "struct" module to allow for nested structures, etc.
> 
> 2) We could define a Python object that specifically carries data-format 
> information.

To distinguish between these, convenience of usage (and of construction)
should have to be taken into account. At least for the preferred
alternative, but better for the runners-up, too, there should be a
demonstration on how existing modules have to be changed to support it
(e.g. for the struct and array modules as producers; not sure what
good consumer code would be).

Suppose I wanted to change all RGB values to a gray value (i.e. R=G=B),
what would the C code look like that does that? (it seems now that the
primary purpose of this machinery is image manipulation)

> The problem with 2b is that what works inside an extension module may 
> not be the best option when it comes to communicating across multiple 
> extension modules.   Certainly none of the extension modules have argued 
> that case effectively.

I think there are two ways in which one option could be "better" than
the other: it might be more expressive, and it might be easier to use.
For the second aspect (ease of use), there are two subways: it might
be easier to produce, or it might be easier to consume.

Regards,
Martin