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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4