[Python-Dev] graphics maths types in python core?

Lino Mastrodomenico l.mastrodomenico at gmail.com
Sun Apr 5 13:17:20 CEST 2009


2009/4/5 Antoine Pitrou <solipsis at pitrou.net>:
> Nick Coghlan <ncoghlan <at> gmail.com> writes:
>>
>> That's largely because parts 2 and 3 are somewhat use case challenged:
>> the key motivation behind PEP 3118 was so that libraries like NumPy, PIL
>> and the like would have a common standard for data interchange.
>
> If I understand correctly, one of the motivations behind memoryview() is to
> replace buffer() as a way to get cheap slicing without memory copies (it's used
> e.g. in the C IO library). I don't know whether the third-party types mentioned
> above could also benefit from that.

Well, PEP 3118 is useful because it would be nice having e.g. the
possibility of opening an image with PIL, manipulate it directly with
NumPy and saving it to file with PIL. Right now this is possible only
if the PIL image is first converted (and copied) to a new NumPy array
and then the array is converted back to an image.

BTW, while PEP 3118 provides a common C API for this, the related PEP
368 proposes a standard "image protocol" on the Python side that
should be compatible with the image classes of PIL, wxPython and
pygame, and (mostly) with NumPy arrays.

I started an implementation of PEP 368 at:

    http://code.google.com/p/pyimage/

Both the PEP and the implementation need updates (pyimage already
includes an IEEE 754r compatible half-precision floating point type,
aka float16, that's not yet in the PEP), but if someone is interested
and willing to help I may start again working on them.

Also note that the subjects "vec2, vec3, quaternion, etc" (PEP 3141)
and "multi-dimensional arrays" (PEP 3118) are mostly unrelated.

-- 
Lino Mastrodomenico


More information about the Python-Dev mailing list