tim_one at email.msn.com
Sat Feb 26 09:08:24 CET 2000
> The idiom "return f(something)" is used almost exclusively by this anal
> retentive bunch I'm proud to be part of <wink>.
Moshe, this simply isn't true -- I found *thousands* of instances of this in
the Python code on my disk, only a fraction of a percentage of which is
playing "functional language" tricks. And when e.g.
return string.join(pieces, sep)
blows up because sep has a ridiculous type, or
return UnboundedFloat(mantissa, exponent, base)
blows up because the base is < 0, or
etc, times at least thousands
blows up, I want to know where it was called *from*. There's nothing unique
to functional styles about reducing a problem to an instance of another
problem, and that's all "return f(something)" really means.
> And I don't mind at all having Python do no optimization as long as I
> do not give the flag -believe-me-I-really-do-want-tail-call-
> optimization <0.5 wink>
I'm afraid it's not that simple (but what is <wink>?). If Python has a mode
that guarantees to optimize tail calls, some people will use it, some of
those will write code that *relies* on it to avoid blowing the stack, some
of those will distribute modules so relying, and then users get sucked into
either (a) running code that uses those modules with the magic switch too,
or (b) not using the switch and suffering "mysterious data-dependent
failures". Both complicate Python's story and so Python users' lives too.
It's a tradeoff in practice: perhaps *you* wouldn't do this to users, but
others will. A language is doomed to support everything it permits, and
> As this flag has very little semantic effect (after all, it is an
> optimization), I don't think there should be any problems with it, except
> 1. I don't care *enough* to write the patch
> 2. Guido probably won't like it
No argument there <wink>.
> disagreeing-with-Guido-and-the-timbot-is-scary-ly y'rs, Z.
it's-only-half-as-scary-if-you-think-we're-the-same-ly y'rs - tim
More information about the Python-list