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

[Nick Coghlan]

Antoine Pitrou wrote:
> Nick Coghlan <ncoghlan <at> gmail.com> writes:
>> Parts 2 and 3, being the memoryview API and support for the new protocol
>> in the builtin types are the parts that are currently restricted to
>> simple linear memory views.
>>
>> 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.

Yep, once memoryview supports all of the PEP 3118 semantics it should be
usable with sufficiently recent versions of NumPy arrays and the like.
It's implementation has unfortunately lagged because those with the most
relevant expertise don't need it (they access the objects they care
about through the C API), and there are some interesting semantics to
get right which are hard to judge without that expertise.

Still, as both you and Greg have pointed out, even in its current form
memoryview is already useful as a replacement for buffer that doesn't
share buffer's problems - it's only if they try to use it with the more
sophisticated aspects of the PEP 3118 API that people may be
disappointed by its capabilities.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------