[Python-Dev] PEP 308: "then" "else" for deprecating "and" "or" side effects

[Stephen Horne]

On Fri, 14 Feb 2003 11:07:56 +0100, "M.-A. Lemburg" <mal at lemburg.com>
wrote:

>The tendency to let inling features creep into the language
>makes me a little nervous. The simplicity of Python is
>losing big with each new way to put more information
>on one line. This can be compared to lossy compression
>of an image: you can still grasp the general picture, but
>the details become unsharp and distored.
>
>Complexity should be reserved to what you write, not
>how you write it.

I disagree with this. It sounds like the old 'sufficiency' argument -
for example "you shouldn't have a subtract operator because addition
and negation are sufficient".

What makes mathematics powerful is not the same as what makes complex
programs readable and maintainable. If you ask the average person
which they are least able to follow, they will typically say algebra
or calculus rather than English for instance.

In English I can say 'if you want something buy it, otherwise don't' -
syntactically a little different to the standard Python if, but
clearly an imperative if structure with equivalent semantics. But I
can also say 'Add sugar, either two if you want it sweet, else just
one'. That is NOT an imperative if statement, it is equivalent to the
PEP308 suggestions - it selects from two values, not two actions.

Readable and maintainable programs express each abstraction in its
most natural form, not obscuring it by forcing it into some unnatural
form just because it is 'sufficient' to express them. The penalty for
poor expressing things in an unnatural way may be small in a program
of a few hundred lines or less, but in larger programs they cause
major problems.

I'm not sure about the various syntax proposals, and I wouldn't be
that worried if PEP 308 was dropped either (despite the above
argument, there are issues that have much bigger impact on readability
and maintainability - the old OO buzzwords of encapsulation, data
hiding etc spring to mind). Also, despite my previous post on the '...
then ... else ...' syntax proposal, my preference would be the
function-like...

  if ( cond, true-value, false-value )

The fact that the arguments are lazy-evaluated is not, in my mind, a
sufficient reason for claiming it isn't a function. Filter, map and
reduce are also slightly unconventional (in that they take functions
as parameters) but just because a function uses functional language
(rather than imperative language) ideas, it doesn't mean that it isn't
a function.

Lazy evaluation also does not mean it is a macro or inline -
functional languages which support lazy evaluation don't even
understand the idea of a macro or inline.

>From a familiarity point of view, I'd also point out that even
spreadsheets such as Excel provide a built-in function like this.

The idea of 'then' as an assertion that triggers backtracking on
failure, and 'else' as an operator that can trap backtracking and
provide an alternative is interesting, but probably just too obscure
as well as a pain to implement - the relative popularity of Icon and
Python make that point.

Personally, I could be very enthusiastic if offered a built-in if
function that used lazy evaluation for its parameters. If an
operator-based form was to be used, I'd like a prefix to the syntax to
tell me that a conditional expression is coming (because, despite many
years of C and C++ programming, I still hate the ternary operator),
leading to something like...

  either x if c1 else y if c2 else z

Hmmm

print either (x / y) if (y != 0) else "Error"

I could live with that. I wouldn't want to overuse it, but that
applies to any syntax.

-- 
steve at ninereeds dot fsnet dot co dot uk