PEP 308: "then" "else" for deprecating "and" "or" side effect s

[Stephen Horne]

On Fri, 14 Feb 2003 14:16:42 -0500, "Chermside, Michael"
<mchermside at ingdirect.com> wrote:

>Stephen Horne writes:
>> Just because it uses lazy evaluation doesn't mean it isn't a function.
>
>I disagree. To me, the semantics of function call is well-defined
>in Python. It works the same way for all functions,

Really - and what about lambdas, which require a closure containing
variables referenced from the enclosing scope (rather like implicit
parameters) when the lambda definition was 'executed'?

Or what about generators, where what looks like a function call is
actually calling an already-running block of code in a scheme that is
somewhat like cooperative multitasking?

Besides that, what about all the things that _are_ function calls but
don't look like it - such as the comparison operators when comparing
class instances that have __eq__ and similar member functions defined?

There is no one-to-one relationship between the conventional syntax of
a function call and the conventional semantics of a function call.
It's pretty hard to think of a language where such an absolute mapping
exists. And neither should there be. A call is always a call - we
specify the name of the function and its parameters and what to do
with the result. The details of what the function does are in that
functions declaration and definition, or, for built-in functions, in
the manual. That is the whole point of functions - to re-use semantics
that were defined and implemented elsewhere.

I don't see why the existence of lazy evaluation should be any
different to any other aspect of the parameters, such as type
restrictions or the possible existence of default parameters, or to
any other aspect of the function, such as whether it has side effects.

In fact, if there was any feature of functions that needed an advance
warning it would definitely be side-effects. If Pythons history could
be conveniently brushed aside, I would quite cheerfully suggest a
requirement that made it impossible for a function which returns a
value to have side-effects unless the declaration had a special flag.
But even for this, I'd still use the same call syntax.

And what I wouldn't give to be able to write...

  def IF (p_Cond, lazy p_True, lazy p_False) :
    if p_Cond : return p_True
    return p_False

-- 
steve at ninereeds dot fsnet dot co dot uk