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

Guido van Rossum guido at python.org
Tue Sep 4 23:55:28 CEST 2007

By all means do write up a PEP -- it's hard to generalize from that one example.

On 9/4/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

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 addelementwise(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

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list