[Python-Dev] Product function patch [issue 1093] (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Tue Sep 4 23:26:32 CEST 2007

Guido van Rossum wrote:

I still don't see why the standard library needs to be weighed down with a competitor to numpy.

The way to get things done efficiently with an interpreted language is for the language or its libraries to provide primitives that work on large chunks of data at once, and can be combined in flexible ways.

Python provides many such primitives for working with strings -- the string methods, regexps, etc. But it doesn't provide any for numbers, and that strikes me as an odd gap in functionality.

What I have in mind would be quite small, so it wouldn't "weigh down" the stdlib. You could think of it as an extension to the operator module that turns it into something useful. :-)

And, as I said, if it's designed so that numpy can build on it, then it needn't be competing with numpy.

Including a subset of numpy was considered in the past, but it's hard to decide on the right subset.

What I'm thinking of wouldn't be a "subset" of numpy, in the sense that it wouldn't necessarily share any of the numpy API from the Python perspective. All it would provide is the minimum necessary primitives to get the grunt work done.

I'm thinking of having a bunch of functions like

add_elementwise(src1, src2, dst, start, chunk, stride)

where src1, src2 and dst are anything supporting the new buffer protocol. That should be sufficient to support something with a numpy-like API, I think.

-- Greg

More information about the Python-Dev mailing list