[Python-Dev] PEP: Adding data-type objects to Python
Travis E. Oliphant
oliphant.travis at ieee.org
Sun Oct 29 09:26:38 CET 2006
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>> What is needed is a definitive way to describe data and then have
>> all be compatible with that same method. That's why I'm proposing the
>> PEP. It's a unification effort not yet-another-method.
> As I unification mechanism, I think it is insufficient. I doubt it
> can express all the concepts that ctypes supports.
Please clarify what you mean.
Are you saying that a single object can't carry all the information
about binary data that ctypes allows with it's multi-object approach?
I don't agree with you, if that is the case. Sure, perhaps I've not
included certain cases, so give an example.
Besides, I don't think this is the right view of "unification". I'm not
saying that ctypes should get rid of it's many objects used for
interfacing with C-functions.
I'm saying we should introduce a single-object mechanism for describing
binary data so that the many-object approach of c-types does not become
some kind of de-facto standard. C-types can "translate" this
object-instance to its internals if and when it needs to.
In the mean-time, how are other packages supposed to communicate binary
information about data with each other?
Remember the context that the data-format object is presented in. Two
packages need to share a chunk of memory (the package authors do not
know each other and only have and Python as a common reference). They
both want to describe that the memory they are sharing has some
underlying binary structure.
How do they do that? Please explain to me how the buffer protocol can be
extended so that information about "what is in the memory" can be shared
without a data-format object?
More information about the Python-Dev