PEP 285: Adding a bool type

[Alex Martelli]

Lulu of the Lotus-Eaters wrote:

> |Lulu of the Lotus-Eaters wrote:
> |major = len([1 for f in fs if f(o)]))
> 
> Alex Martelli <aleax at aleax.it> wrote:
> |I personally prefer:
> |major = len(filter(None, [f(o) for f in fs]))
> 
> Why?  I had thought of basically that one.  But the short "if f(o)"
> clause seemed to read better than the longer "filter(None..)" construct.

Musing along in introspection...:

If it wasn't for the need of having meaningless contents in the
list built by the comprehension, maybe.  It takes an epsilon of
reflection to realize "the contents are irrelevant", which for
some reason the idiom starting with "len(filter(None, " does not
seem to require of me (maybe because I've seen that idiom so many
other times).

Funny enough, [f for f in fs if f(o)] reads better to me -- maybe
because it DOES a more similar job to filter, rather than choosing 
"arbitrary" contents.  A subtle issue indeed, given the len( ...
clarifies at once that the contents don't matter, and yet that's
how it feels to me.

> I don't really care one way or another about mixing filter() with
> listcomps, but the few extra keystrokes in Alex' don't seem to add to
> clarity.

Certainly not to a hypothetical reader not familiar with filter(None, ...
(who'd have to look it up).  Just as apply is close to obsolete due
to the * and ** forms for actual arguments, so maybe I should try to
think of filter and map similarly -- and yet while I love list
comprehensions, filter and map appear so natural to me when they don't
need a (yecch) lambda.


> Another option is to squeeze a reduce(operator.add...) into there.  But
> practically, len() seems to do everything that needs doing.

Basically MLH's suggestion, right?  No, it seems to me that len is
quite superior to +/ (as we spelled reduce(add... back in APL) here --
simpler, more obvious, and not needing ones and zeroes specifically
(faster, too -- minor consideration of course, but...).


Alex