Travis Oliphant wrote:
> Nick Coghlan wrote:
>> 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.
It may make sense to have a couple distinct sections in the datatype PEP:
a. describing data formats with basic Python types
b. a lightweight class for parsing these data format descriptions
It's most of the way there already - part A would just be the various styles
of arguments accepted by the datatype constructor, and part B would be the
datatype object itself.
I personally think it makes the most sense to do both, but separating the two
would make it clear that the descriptions can be standardised without
*necessarily* defining a new class.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
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