Show HN: A set of handy tools to work with sequences and collections in Python | Hacker News Reader

Show HN: A set of handy tools to work with sequences and collections in Python

github.com

29 pointsSuor10 comments

Nice. Thought I am glad I do my main work in C# where all of this can be easily achieved with LINQ without any need for additional libraries http://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b

All of this can be achieved in Python without additional libraries using list and generator comprehensions - this library just provides some extra syntactic sugar.

That extra syntactic sugar is what Parent was talking too. Much of c#3 and later were designed with LINQ and other facilities in mind.

the interface to "where" could use a little rethinking. not all keys are constant string values that are legal identifiers. e.g.

    where([{1 : 'a', 2 : 'b'}, {1 : 'b'}], 1='a')
    SyntaxError: keyword can't be an expression


    where([{1 : 'a', 2 : 'b'}, {1 : 'b'}], **{1:'a'})
    TypeError: where() keywords must be strings

edit: this is based on my own naive "where" implementation, but these are limitations of the language

Yes, where() doesn't handle that case, but it makes its interface more smooth for more common case of string keys.

That was a deliberate choice.

    some([0, '', -1, None, 2]) # -1

should be

    some(odd, [0, '', -1, None, 2]) # -1

Predicate in some() is optional. A test for boolean truth is used in that case.

So, first example is the same as:

    some(bool, [0, '', -1, None, 2])

Nicely done. I would have killed for this on a recent project doing machine vision.

There are many thing in here that are already in functools, itertools (!), or the standard builtins (!!). Please do not shadow builtin names, and consider removing things that are already in itertools, as they will be faster than pure-Python code.

Yes, that decisions look dirty and dubious, but using funcy for several months, I've come to that practicality and convenience is worth it.

Some of itertools things are just reexports and builtins are extended purely - so that they behave the same given same arguments - with negligible performance overhead.

Anyway, if you are such a purist you still have at least two options: 1. just `import funcy` and use it as `funcy.map(...)` or `funcy.keep(...)` 2. Import only functions you use, avioding name clashes, use `from funcy import map as xmap` to import extended builtins.

Reply on news.ycombinator.com