functional programming

[Tim Peters]

[Moshe Zadka]
> 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
usually forever.

> 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
> two:
>
> 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