[Python-Dev] graphics maths types in python core? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sun Apr 5 13:16:25 CEST 2009

Antoine Pitrou wrote:

Nick Coghlan <ncoghlan 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

More information about the Python-Dev mailing list