Some Python 2.1 ideas

[Alex Martelli]

"Jay O'Connor" <joconnor at cybermesa.com> wrote in message
news:mailman.977616128.3537.python-list at python.org...
> >It's my guess that one reason Python
> >doesn't support this is to make "=" illegal inside expressions, thus
> >avoiding the "=" vs. "==" errors common in C. A response to that
objection
> >is to use a different token for embedded assignment
>
> Another response to that objection would be that languages that support
> a proper Boolean type do not exhibit errors based on "=" versus "=="

And that response would be a falsehood (as well as a non-sequitur).  If
falsehoods and non-sequiturs are to be counted, the number of responses
grows without bounds, and their usefulness decreases accordingly.


The non-sequitur part comes from the fact that the (erroneous) concept
behind this only applies (partially) to statically-typed languages; in a
dynamic
one, the TypeError hypothetically raised by (Python syntax augmented with
assignment-as-expression, hypothetical if-needs-a-Boolean semantics):
    if x = someFun():
when someFun does not return a Boolean is obviously 'exhibited' at runtime.

If 'if' raises an exception when applied non-Boolean expressions, the error
may get 'exhibited' in a marginal more clear way, but that is all.  If you
want
compile-time type-checking, you know where to find it... NOT in Python!


The falsehood part comes from that nice 'when' clause: when someFun DOES
return a Boolean... bye-bye.  E.g., same setting:

def howManyCopies(value, sequence):
    count = 0
    for item in sequence:
        if value = item:
            count += 1
    return count

The 'if', here, "exhibits" the classic =/vs/== error; the result will be the
number of True items in the sequence of Boolean values 'sequence', not,
as desired, the number of items that are equal to the 'value' argument.

Even if a language let you constrain value and item to be Booleans, still,
if assignment is part of an expression, the error can still perfectly well
be 'exhibited' -- each and every time a programmer wants to check the
equality of Boolean values and erroneously assigns them instead!

This is such a well-known pitfall in Java (which does have static type
checking and 'proper boolean type') that it's incredible to think one could
overlook it.


To avoid the =/== confusion, while keeping = for assignment (and
accepting it in expressions) and == for equality-test, a language has
to model truth/falsity as a NON-type -- something that cannot possibly
be 'assigned' to a variable.  Snobol and Icon point the way.  Relational
and logical operators could hinge on transient success/failure conditions,
and 'if' and 'while' be constrained to accept such a condition (NOT an
'expression'!), which could not be 'assigned' to anything.  Then:
    if value = item:
would fail to compile, because an expression follows the 'if' and that
would be unacceptable;
    if value == item:
would compile, as '==' would not be an expression-forming operator,
but rather a condition-forming one.  and, or would also have to work
on conditions and result in conditions.  A few other frills would also
have to exist -- specifically, some explicit way to turn a condition into
some value that can be stored, for example a ternary operator like C's
?: or some syntax-sugar variation of it:
    saveConditionForLater = (value==item)?1:0
to be tested later on as
    if saveConditionForLater == 1:

_This_ Copernican revolution, at large 'conceptual' cost, would then
finally let one write things like:
    while (line=file.readline()) != '':
[I parenthesize explicitly here, as I did above in the example of ?:,
because the precedences of these constructs would be anything but
obvious; it would probably be best to enforce the parentheses...].

Now this _could_ be the basis of a self-consistent language.  I think
it would be usable, but inferior to Python, because of all the extra
conceptual baggage: above all the condition/expression split.  Entia
non sunt multiplicanda praeter necessitatem, and I opine this deep
semantic split (which DOES, indisputably, 'multiply entities') goes
well beyond 'necessity' -- it 'multiplies' them in the misguided quest
for *convenience*, in whose name so many sins are committed.

Remember, "A designer knows he has achieved perfection not when
there is nothing left to add, but when there is nothing left to take
away"... the designer of this hypothetical language should realize
the condition/expression split *is* 'left to take away' -- and taking
it away (as well as the 'convenient' but NOT 'necessary' ternary op,
and assignment-as-expression) would yield Python again.


Alex