greg.ewing at canterbury
Sep 4, 2007, 2:26 PM
Post #13 of 25
(512 views)
Permalink
|
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/list-python-dev%40lists.gossamer-threads.com
|
