Travis E. Oliphant wrote: > However, the existence of an alternative strategy using a single Python > type and multiple instances of that type to describe binary data (which > is the NumPy approach and essentially the array module approach) means > that we can't just a-priori assume that the way ctypes did it is the > only or best way.
As a hypothetical, what if there was a helper function that translated a description of a data structure using basic strings and sequences (along the lines of what you have in your PEP) into a ctypes data structure? > The examples of "missing features" that Martin has exposed are not > show-stoppers. They can all be easily handled within the context of > what is being proposed. I can modify the PEP to show this. But, I > don't have the time to spend if it's just all going to be rejected in > the end. I need some encouragement in order to continue to invest > energy in pushing this forward. I think the most important thing in your PEP is the formats for describing structures in a way that is easy to construct in both C and Python (specifically, by using strings and sequences), and it is worth pursuing for that aspect alone. Whether that datatype is then implemented as a class in its own right or as a factory function that returns a ctypes data type object is, to my mind, a relatively minor implementation issue (either way has questions to be addressed - I'm not sure how you tell ctypes that you have a 32-bit integer with a non-native endian format, for example). In fact, it may make sense to just use the lists/strings directly as the data exchange format definitions, and let the various libraries do their own translation into their private format descriptions instead of creating a new one-type-to-describe-them-all. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com