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 | [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
