Hacker News Reader

Comment by masklinn | Hacker News Reader

Note that more of them have been merged to recent Pythons than just the top: the `dict` constructor can now take kwargs (and a first dict argument, which means you can create an extended copy of dict d with `dict(d, foo='bar', baz='buzz')`), there's a `collections.defaultdict` in 2.5, `namedtuple` in 2.6 is pretty similar to his Struct (though not exactly, `namedtuple` is a type builder, Norvig's `struct` is basically a dict with args instead of items).

`every` and `some` can be emulated by composing `map` (or a listcomp) with the builtin `any` and `all` (which, for some reason, don't take an optional predicate)

View on HN

`every` and `some` can be emulated by composing `map` (or a listcomp) with the builtin `any` and `all` (which, for some reason, don't take an optional predicate)

No they can't - this version wouldn't short circuit evaluation, which is completely the wrong behavior. Map would have to apply the predicate to every element of the list before any/all kicked in.

As a trivial example, consider I had a million item list and want to find out if every element is prime. If 8 is the first element, 'every' would return false after looking at the first item - while your composition would apply the prime predicate to all million elements (which would be ridiculously slow ...) before even starting to apply 'all' (which would short circuit, after seeing the first false).

If you have enough elements to desire short circuit evaluation you can, as `masklinn` mentioned, use a list comprehension. Specifically a generator list comprehension.

http://www.python.org/dev/peps/pep-0289/

    big_list = make_big_list()
    if any( not prime( a ) for a in big_list ) :
      do_thing()

When you surround the list comprehension syntax with parenthesis instead of square brackets, either as a lone argument to a function or independently, you create a generator that will iterate once over the given data.

This allows for functions accepting sequences to short circuit without completing the function mapping.

> No they can't - this version wouldn't short circuit evaluation, which is completely the wrong behavior. Map would have to apply the predicate to every element of the list before any/all kicked in.

Just use the lazy map itertools.imap (or Python 3, where `map` is lazy) or replace listcomps by gencomps, any & all take any iterable if you're worried about that. Stop creating problems where there is none.

"(which, for some reason, don't take an optional predicate)"

This kills me pretty much every time I use those functions. It seems like 9 times out of 10, I need the ability to pass in a predicate function.

This always struck me as a major oversight... does anyone know if this design decision was made for a particular reason?

You want to be able to say all(items, lambda x: x.is_cool()) instead of all(item.is_cool() for item in items)? The second one seems clearer to me and isn't substantially longer.

Good point. I guess usually crops up when I've already got a predicate function handy and I want to say `all(items, f)`. I always just expect that to work for some reason. Using a generator expression works just as well, though, and is probably clearer in the long run.

Besides, I guess if `any` had a signature like

    def any(xs, pred=lambda x: bool(x))

or something, that would reverse the signatures of map, filter, reduce, etc.

On that note, I always want the arguments of filter and reduce, but not those of map, to be reversed for some reason.

If you already have a predicate function, it is not hard to say

  all(filter(f, items))

Composing calls like this looks cleaner than incorporating into the function interface all list manipulations that the implementor expects you to want.

Said before, but any(pred(x) for x in xs) is too complex?

Quoting myself, now: "Using a generator expression works just as well, though, and is probably clearer in the long run."

It's just that my first instinct is always to use all(xs, pred).

Reply on news.ycombinator.com