On Tue, Dec 20, 2011 at 7:03 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Tue, Dec 20, 2011 at 12:45 PM, Nathan Rice
> <nathan.alexander.r...@gmail.com> wrote:
>> There are still some issues with proper support of things like bool()
>> and int(), which refuse to return things that are not of the correct
>> type.
>
> And that's a good thing. As type conversion functions, bool(x) and
> int(x) should *always* return bools and ints respectively (or raise an
> exception), no matter what you pass in for x.
I was hoping to have the proxy be completely transparent. I don't
disagree with your statement though.
> If I do "list(efoo)", where efoo is an ElementwiseProxy object, should
> I expect to get the efoo collection converted to a list, or another
> ElementwiseProxy where each element has been converted to a list? I
> would hope the former.
Iterators are how you go from an ElementwiseProxy back to a regular
collection. Thus list/set/etc or anything that takes an iterator will
work.
>> This was developed as a proof of concept for expanding the role of
>> element-wise syntax in python, and to that end I welcome comments.
>
> The examples you gave are all numerical in nature. If I might
> inquire, what might I use this for that I can't already do with numpy?
efoo2 = ElementwiseProxy(["one", "two", "three", "four"])
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
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.
Nathan
--
http://mail.python.org/mailman/listinfo/python-list
