Nick Coghlan wrote: > 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? > That would be fine and useful in fact. I don't see how it helps the problem of "what to pass through the buffer protocol" I see passing c-types type objects around on the c-level as an un-necessary and burdensome approach unless the ctypes objects were significantly enhanced. > > 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. Yes, I'm open to this possibility. I basically want two things in the object passed through the extended buffer protocol: 1) It's fast on the C-level 2) It covers all the use-cases. If just a particular string or list structure were passed, then I would drop the data-format PEP and just have the dataformat argument of the extended buffer protocol be that thing. Then, something that converts ctypes objects to that special format would be very nice indeed. -Travis
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4