[Python-Dev] PEP: Adding data-type objects to Python

["Martin v. Löwis"]

Travis E. Oliphant schrieb:
> But, there are distinct disadvantages to this approach compared to what 
> I'm trying to allow.   Martin claims that the ctypes approach is 
> *basically* equivalent but this is just not true.

I may claim that, but primarily, my goal was to demonstrate that the
proposed PEP cannot be used to describe ctypes object layouts (without
checking, I can readily believe that the PEP covers everything in
the array and struct modules).

> It could be made more 
> true if the ctypes objects inherited from a "meta-type" and if Python 
> allowed meta-types to expand their C-structures.  But, last I checked 
> this is not possible.

That I don't understand. a) what do you think is not possible? b)
why is that an important difference between a datatype and a ctype?

If you are suggesting that, given two Python types A and B, and
B inheriting from A, that the memory layout of B cannot extend
the memory layout of A, then: that is certainly possible in Python,
and there are many examples for it.

> A Python type object is a very particular kind of Python-type.  As far 
> as I can tell, it's not as flexible in terms of the kinds of things you 
> can do with the "instances" of a type object (i.e. what ctypes types 
> are) on the C-level.

Ah, you are worried that NumArray objects would have to be *instances*
of ctypes types. That wouldn't be necessary at all. Instead, if each
NumArray object had a method get_ctype(), which returned a ctypes type,
then you would get the same desciptiveness that you get with the
PEP's datatype.

> I'm happy to have the data-format object live separate from ctypes and 
> leave it to the ctypes author(s) to support it if desired.  But, the 
> claim that the extended buffer protocol jump through all kinds of hoops 
> to conform to the "ctypes standard" when that "standard" was designed 
> with a different idea in mind is not acceptable.

That, of course, is a reasoning I can understand. This is free software,
contributors can chose to contribute whatever they want; you can't force
anybody to do anything specific you want to get done. Acceptance of
any PEP (not just this PEP) should always be contingent on available
of a patch implementing it.

> Where is the discussion that crowned the ctypes way of doing things as 
> "the one true way"

It hasn't been crowned this way. Me, personally, I just said two things
about this PEP and ctypes:
a) the PEP does not support all concepts that ctypes needs
b) ctypes can express all examples in the PEP
in response to your proposal that ctypes should adopt the PEP, and
that ctypes is not good enough to be the one true way.

Regards,
Martin