"for" with "else"?

[Alex Martelli]

Stephen Horne wrote:
   ...
>   def always (pred, seq) :
>     for i in seq :
>       if not pred(i) : return False
>     return True
> 
> While these 'every' and 'always' functions are trivial, they are also
> pretty useful and obviously based on the common discrete maths
> notation so not unique to me.
> 
> Could some simple functions like this have a place in the library
> somewhere?

They might, *EXCEPT* that "passing a callable" is out of fashion, and
out of favour, in the BDFL's current opinion -- and for good reasons,
too, although they MIGHT change in the future.  The BDFL is on record
as regretting ever having accepted lambda into the language, and map,
filter and reduce into the languages' builtins; 3.0 (maybe in 2-3 years)
will be mostly about *simplification*, i.e. *removal* of some of the
"more than one way" things that have accreted over the years, and in
that release lambda and the 'functional'-ish built-ins are quite likely
to go (the latter might get moved to some backwards-compat module); such
new language features as list comprehensions have among their major pluses
the ability to NOT "pass callables" but rather write code in-line.

So I strongly doubt that any new construct *ENCOURAGING* people to
write "if always(lambda x: x>23, myseq):" and the like stands any
substantial chance of getting into the language and built-ins.  I
could be wrong, of course; channeling Guido is Tim Peters' job, not
mine.  But if you could figure out a GOOD Pythonic way to pass an
anonymous codeblock into a function, as e.g. Ruby and Smalltalk do
so naturally -- particularly a good SYNTAX, that's the hardest part --
THEN you might stand a good chance of "revolutionizing" Python, at
least at 3.0 time.  The ability to code predicates inline would be
key, here.  Neither:
    if always(lambda x: x>23, myseq):
       ...
nor:
    def gt23(x): return x>23
    if always(gt23, myseq):
       ...
are currently considered GOOD.  What might be?  I dunno.  Ruby's
concepts (that the block, if present, always goes AFTER the function;
only one block can be there, at most; ...) might be acceptable limits
if they helped a good syntax; lambda's current limit (no statements,
just an expression -- and all the distortions THAT encourages) is
not acceptable.

E.g., suppose (and I doubt it IS so in reality:-) that making 'def'
do double duty was deemed acceptable; 'def' would denote a statement
when used like today, but it might also be an _expression_ instead,
if and only if used as the last actual-argument to a function, a la:

if always(myseq, def isgood(x): return x>23):
   ...

or:

if always(myseq, def memoized_predicate(x):
                     try: return _memo[x]
                     except KeyError:
                         _memo[x] = lots_of_computations(x)
                         return _memo[x]
         ):
   ...

THEN, _IF_ the BDFL liked this specific syntax (and, to repeat,
I strongly doubt he would!!!), you MIGHT well get your 'always',
'exists', etc etc -- and many other neat ideas currently held
in limbo because of the "passing a callable" issue might also
get "unblocked".  Among the problems is, there is no precedent
for an _expression_ being whitespace/indentation sensitive, yet
something like that would be indispensable for any such idea...


Alex