[Numpy-discussion] Numeric3

[Ralf Juengling]

On Mon, 2005-02-07 at 01:56, konrad.hinsen at laposte.net wrote:
> Note that all his examples are cases where Python chose to use 
> functions where OO principles would suggest methods. If abs(), round(), 
> min() etc. were methods from the start, there wouldn't be any problem 
> to solve (of course they are not for a very good reason: notational 
> habit). The same applies to the math module or the ufunc module in 
> Numeric - there would be no need for ufunc if math simply defined 
> syntactic sugar for method calls.

No, the idea behind using function calls rather than method calls
is actually a little more than just a difference in syntax. It 
allows for a generic implementation that works in all cases of 
reasonable input, that is, it also works in cases where no efficient
implementation is provided by the input object. A simple example:

>> class DumbList(list):
...     def __len__(self):
...         raise NotImplementedError
...
>>> def len(sequence):
...     try:
...         return sequence.__len__()
...     except:
...         n=0
...         for item in sequence: n+=1
...         return n
...
>>>
>>> len([1,2,3])
3
>>> len(DumbList([1,2,3]))
3


Ralf


> 
> I wonder if it is possible to come up with an abstract API for arrays 
> that would permit alternate implementations to be chosen as late as 
> possible, even at runtime. That could help to get over the 
> Numeric/numarray split.
> 
> Konrad.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion