[Python-Dev] lazy evaluation redux (was dict "setdefault". Feaure request or bugfix?)

[Alex Martelli]

On Tuesday 11 February 2003 03:20 pm, Jesus Cea Avion wrote:
> > OK, you want "lazy evaluation", but only in a very specific case.
>
> Specific but intuitive, useful and efficient, nevertheless.
>
> > MUST continue to ensure each of a and b is called before
> > whatever is -- both for backwards compatibility AND to respect
> > the principle of least astonishment
>
> Well, that a dict's "setdefault" method invokes the argument function
> only when necessary is far more intuitive and logical to me than current
> situation. In fact there are already precendents, like boolean AND
> construction, for example. Or the vary same "zip" built-in lazy
> parameters evaluation works, for example.

There are absolutely no precedents for ANY arguments to Python
callables being lazily evaluated.  Your opinion that the zip built-in
is an exception is seriously (and gravely) wrong.  The operators
and / or _do_ shortcircuit, but they have nothing to do with any
arguments going to any callables.

The rule now is:
  *ANY* time (and I mean *ANY*) you see:
       anycallable ( anargumentexpression )
  FIRST the anargumentexpression is evaluated,
  THEN its result is used as the argument to anycallable

*ALWAYS*.  *EVER*.  *NO* exceptions, EVER.

Your claim is that changing this rule into ones that continues with:
  EXCEPT if the value of anycallable is this very specific one,
      in which case the SECOND argument only isnt ...
is "INTUITIVE"?!

I think you are not applying the right principles of language
design, those on which Python is based: *NO* obscure special
cases, "convenient" shortcuts, "ad-hoc" exceptions.  Languages
that strive to use complicated rules instead of simple ones in
order to "read the programmer's mind" and "do what's most
convenient in a way that depends entirely on the context" are
inevitably destined to go the way of perl or PL/I - to unbearable,
atrocious complexity.


> Yes, lazy evaluation should be very useful although generators and
> iterators helps a lot. But it is not the point that I'd like to study
> here :-).

OK, let's keep "studying" how absurd it would be to make a
totally general, simple, universal rule substantially more complex
to cater for ONE obscure, rare corner case.  I think it makes a
great example on how NOT to design a programming language.


> By the way, thanks for your (and David Ascher) "Python CookBook". I only
> read 1/3 so far, but my money is already well paid :-). Last night I
> went to bet at 4:30 in the morning... };-)

Well, the thanks should really spread to the whole Python community --
over 100 contributors, over a dozen authors of chapter introductions --
but I'll gladly accept them for my own role;-).

But I'll be snide and point out that the idea of making one tiny
exception to a general rule for "convenience" in one obscure case
is easier to understand thinking you've slept little;-).


Alex