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

[Joshua Landau]

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

> efoo_res = ((efoo2.capitalize() + " little indian").split("
> ").apply(reversed) * 2).apply("_".join) # note that you could do
> reversed(...) instead, I just like to read left to right
> efoo_res.parent.parent.parent # same as ((efoo2.capitalize() + "
> little indian").split(" ") in case you need to debug something and
> want to look at intermediate values
>

How is any of this better than the elementwise operators ("~")? People
should be able to expect len(x) to *always* return a number or raise an
error. I know it's not part of the spec, but a lot breaks without these
guarantees. When "str(x)" isn't a string, *all the formatting code breaks**.
And when the other suggestion ("~str(x)" or "str~(x)" or something similar)
has all the benifits and none of the drawbacks, why should I use this?

Upon this implementation I take back my comment on the whole typing thing.
Your title just really confused me.

* You can't just make functions non-elementwise unless called through
".apply" either:
def str(x): return x.__str__()

Also note that I'm ignoring that "~" has a predefined meaning, making
"~func(x)" valid already. That's a minor syntactic point, not a point of
the proposal, that i stuck with just 'cause of the PEP.

The idea is to provide a syntax that lets you do very complex things
> on collections in a more readable manner, without having 5 or 6 lines
> of generator expressions.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20111221/b7d4b75a/attachment-0001.html>