[Python-Dev] Product function patch [issue 1093]

[Guido van Rossum]

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
>
>    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
> _______________________________________________
> 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/)