5 comments

[ 3.3 ms ] story [ 24.0 ms ] thread
To me, foo.where(...) looks a bit cleaner than a function call such as filter(..., foo). But writing foo.skip(4) instead of foo[4:] is just silly.

This library consists of very thin wrappers around functionality that's available out of the box in Python. Are these wrappers worth an extra dependency? I think a cheat sheet for people coming from .NET would be more useful than implementing a similar API.

I prefer list comprehension's syntax. I could respect this if it was also faster maybe. To me lambdas are kind of clunky in Python, and I've never been impressed with the .NET Object Oriented builder way of dealing with lists. If you don't format it well(which frankly is kind of difficult to do) you can end up with many very long lines.
You hate python so you made a library to make it look worse, but at least less pythonic? I believe someone will find it useful and it frightens me
For the example

    teenagers = people.where(lambda p: 20 >= p.age >= 13)
I prefer the good ol' Pythonic way

    teenagers = filter(lambda p: 13 <= p.age <= 20, people)
because I know how filter behaves, but am I certain that `where` gives me the elements not their indices (cf. `numpy.where`)?

In another example

    ages = people.age
The Pythonic way can be

    ages = [p.age for p in people]
Despite having more characters to type, list comprehension is a well-known idiom and I bet many Python programmers would be able to write it down in a second or two.

And how would `old_people.last()` be any clearer than `old_people[-1]`? At least from these examples, I'm not convinced it makes a strong case to switch to the .NET Lists.

Python also has

    [p for p in people if 20 >= p.age >= 13]
which someone (I, for one) might find more readable than both the proposed `where` method and the `filter` builtin