4 ms·
Side note: you can simply use sum(p(x)) for x in xs), assuming p is a predicate. It's a neat trick, though a bit slower than your ternary version.
by bdr 14y ago
Side note: you can simply use sum(p(x)) for x in xs), assuming p is a predicate. It's a neat trick, though a bit slower than your ternary version.
- bjourne 14y agoAnother way: len(filter(p, xs))
- daeken 14y agoWith the sum approach the data set never exists in memory, but is generated as needed; not a big deal for a small set, but it can add up.
- lclarkmichalek 14y agoAnd as in python3, filter returns a generator, not a list, the len call will fail altogether.
- bjourne 14y agoYes, I'm aware of that. But my philosophy is to always try to conserve keystrokes wherever possible. Premature optimization is the root of all evil and all that. :) For the same reason I prefer to use dict.items() over dict.iteritems() and range() over xrange() and so on.
- slurgfest 14y agoThis is a simple enough case that I'm not sure it matters, but I think the sum version is simpler to read. Generator expressions are quite powerful if you want to write Python which is more functional-flavored.
- rat87 14y agoI disagree, I think filter/length models the meaning better.
- rat87 14y agoI guess technically True==1 and False==0 in python and it is considered "pythonic" but personally I think it's "ugly".
- bdr 14y agoI wouldn't even say it's Pythonic. As a reader, I would prefer len+filter (or ifilter). That's the most semantically clear.
- rat87 14y agoI also prefer length + filter but while I dislike the style I think it is still considered pythonic. The pep for adding bools to python: http://www.python.org/dev/peps/pep-0285/ http://www.python.org/dev/peps/pep-0285/ 4) Should we strive to eliminate non-Boolean operations on bools in the future, through suitable warnings, so that for example True+1 would eventually (in Python 3000) be illegal? => No. There's a small but vocal minority that would prefer to see "textbook" bools that don't support arithmetic operations at all, but most reviewers agree with me that bools should always allow arithmetic operations. 6) Should bool inherit from int? => Yes. In an ideal world, bool might be better implemented as a separate integer type that knows how to perform mixed-mode arithmetic. However, inheriting bool from int eases the implementation enormously (in part since all C code that calls PyInt_Check() will continue to work -- this returns true for subclasses of int). Also, I believe this is right in terms of substitutability: code that requires an int can be fed a bool and it will behave the same as 0 or 1. Code that requires a bool may not work when it is given an int; for example, 3 & 4 is 0, but both 3 and 4 are true when considered as truth values. Compatibility Because of backwards compatibility, the bool type lacks many properties that some would like to see. For example, arithmetic operations with one or two bool arguments is allowed, treating False as 0 and True as 1. Also, a bool may be used as a sequence index. I don't see this as a problem, and I don't want evolve the language in this direction either. I don't believe that a stricter interpretation of "Booleanness" makes the language any clearer.