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.
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.
5 comments
[ 3.3 ms ] story [ 24.0 ms ] threadThis 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.
In another example
The Pythonic way can be 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.