Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.

Joshua Landau joshua.landau.ws at gmail.com
Wed Dec 21 13:52:37 EST 2011


On 21 December 2011 18:32, Nathan Rice <nathan.alexander.rice at gmail.com>wrote:

> On Wed, Dec 21, 2011 at 1:24 PM, Joshua Landau
> <joshua.landau.ws at gmail.com> wrote:
> > I was under the impression that these were meant to be interchangeable.
> This
> > is because functions are just wrappers to non-functions, really.
> >
> >>>> from elementwise import ElementwiseProxy as P
> >>>> (lambda x:x+[1])(P([[0],[0],[0]]))
> > [0, 1], [0, 1], [0, 1]
> >
> > If we have to use .apply, we might as well use map :P.
>
> Apply is not required, you can use functions.  I just hate reading
> inside out and backwards.  compare:
>
> func3(func2(func1(x))) # Fine if the chain is short, but quickly gets
> unreadable
>
> x.apply(func1).apply(func2).apply(func3) # More verbose when working
> with short chains, but infinitely clearer and more readable when
> things start getting complicated, or for less experienced coders


I wan't disagreeing with that, hence the word "if". I was just making a
counter-counter point to a misunderstanding of my post.


> > Note that "len" and "dir" crash.
> >
> > Here is a perfect example:
> >>>> int(P(["1","2","3"]))
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> > TypeError: __int__ returned non-int (type ElementwiseProxy)
>
> It is alpha software :P  Easily fixed though.
>

If fix means "return number" then no. This inconsistency between
elementwise operations and 'normal' ones is the problem. Again, explicit
elementwise-ifying through "~" fixes that. You need to tell me why this is
worth the confusion over that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20111221/098e9e7c/attachment-0001.html>


More information about the Python-list mailing list