[Numpy-discussion] Numeric3
Ralf Juengling
juenglin at cs.pdx.edu
Mon Feb 7 08:38:28 CST 2005
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
More information about the Numpy-discussion
mailing list