[Numpy-discussion] Numeric3

Andrew Straw strawman at astraw.com
Sun Feb 6 10:13:22 CST 2005


While energy is put into re-coding an array package, I'd like to bring 
up an interesting idea brought up on matplotlib-users by Norbert Nemec: 
http://sourceforge.net/mailarchive/message.php?msg_id=10528079 

Norbert's idea is a solution to the problem of a numeric package 
overriding builtins when doing "from Numeric import *". Currently 
Numeric (23.6) overrides sum() on my system, and numarray (1.2a) 
overrides round(), sum(), and abs(). The respective mlab modules bring 
in min() and max().

(I think we all agree that "from blah import *" is a naughty thing to 
do, but people are going to do it, especially for interactive work, 
especially those who have come from namespace-less languages such as 
matlab.)

Here's Norbert's original email, which I think summarizes the idea nicely.

Norbert Nemec wrote:

> Look at these one by one:
> * abs() already calls an __abs__() method. The clean way to extend it, would 
> therefore be to give arrays such a method. This should solve the problem 
> completely.
> 
> * round() does not seem to be extendable in Python. Maybe we should propose to 
> change Python itself to introduce a __round__ method? That would only be 
> straightforward.
> 
> * min, max and sum are all based on iterating over a sequence. Maybe, one 
> should again have __min__, __max__ and __sum__ which should then be checked 
> by the builtin before falling back to iterating over the sequence? I could 
> imagine many kinds of containers that could optimize these operations. So 
> this would again be a detail that should be changed in Python itself. If the 
> builtin min() function would then also pass on keyword arguments, that would 
> solve our problem completely and thoroughly.
> 
> Does anybody have experience with discussions in the Python forum to estimate 
> how realistic such a PEP would be?
>






More information about the Numpy-discussion mailing list