HN Explorer

11 comments

[ 305 ms ] story [ 865 ms ] thread
msandford
Nicely done. I would have killed for this on a recent project doing machine vision.
urza
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
simonw
All of this can be achieved in Python without additional libraries using list and generator comprehensions - this library just provides some extra syntactic sugar.
manojlds
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.
jmmcd 

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

    some(odd, [0, '', -1, None, 2]) # -1
Suor
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])
shoo
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
Suor
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.

[deleted]
(comment deleted)
MostAwesomeDude
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.
Suor
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.