5 ms·

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

29 points by Suor 13y ago

msandford 13y ago
Nicely done. I would have killed for this on a recent project doing machine vision.
urza 13y ago
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 http://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b
- simonw 13y ago
  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 13y ago
    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 13y ago
some([0, '', -1, None, 2]) # -1 should be some(odd, [0, '', -1, None, 2]) # -1
- Suor 13y ago
  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 13y ago
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 13y ago
  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 13y ago
[deleted]
MostAwesomeDude 13y ago
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 13y ago
  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.

29 points by Suor 13y ago

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

urza 13y ago

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 http://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b

simonw 13y ago
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 13y ago
  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 13y ago

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

Suor 13y ago
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 13y ago

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 13y ago
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 13y ago

[deleted]

MostAwesomeDude 13y ago

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 13y ago
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.