PEP 308: Pep Update

[Norman Petry]

On Thu, 27 Feb 2003 09:23:09 +0000, Robin Becker wrote:

>>1) it uses symbols, rather than keywords, which are meaningless unless
>>the reader is already familiar with the construct from another
>>programming language (since they have no obvious analogue in mathematics
>>or some natural language).  This makes it an especially poor choice for
>>Python, which has important applications as a teaching (i.e. first)
>>language.
>>
>>
> I think you are wrong on this: mathematics, logical calculus,
> engineering et al. all use abstract symbolism. It improves communication
> amongst those in the field. people seem to have little difficulty in
> picking up such syntax.

Yes, abstract symbols can be learned.  In fact, all symbols - even the
words that make up natural languages - only have meaning once they are
learned.  The POINT, however is that reusing symbols that are already
known from another context in an analogous way makes it quick and painless
to learn these meanings.  Therefore, adopting symbols from a natural
language (English), basic mathematics, or Python itself adds little to the
cognitive load of new symbols that must be memorised when the programming
language is learned.

Of course, this is the very reason why programmers coming from a C/C++
background are trying to have the C syntax adopted for the ternary in
Python. The problem though is that Python is often used as a teaching
language, where the learner's antecedents will be found in some natural
language or in mathematics.  The existence of this C?x:y gobbledygook in
programming languages like C and Perl will not help them at all!

> If we rigorously adopted your approach then 'a+y' would have to be
> replaced by 'a add y' or similar. It may be that poor 'dumb' programmers
> can't hack symbols if so we're in real trouble.

No, because that is NOT my approach -- you are trying to set up a strawman
argument here.  It is common sense to reuse the language of mathematics in
the design of programming languages (especially for computing the results
of arithmetic expressions), supplemented as necessary by carefully chosen
keywords from a natural language.  However the C-style ternary isn't found
in these languages and is thus 'meaningless' to anyone not coming to
Python from a C background. This was my original point.

This is why I regard using '=' for assignment, and '==' for equality as a
(sadly now unremediable) blemish in the design of Python.  It reuses a
mathematical symbol (=) for a new purpose in a way that contradicts its
established meaning within that context, thereby creating needless
confusion.  Yet since the concept of equality IS actually needed in the
language, a NEW symbol (==) must be created to represent it.  If '=' means
'equals' (actually no -- it means 'becomes') does '==' mean 'really
equals'?  If so, then perhaps '>>' should mean 'really greater than', and
we should reuse '>' for something else! -- C is truly insane in some ways.

I really hope that Python does not import even more bad ideas like this
from C, or I will need to begin looking elsewhere for a language that
provides readability.

> As to your point about experience I would argue that non english
> speakers are in much the same position wrt 'if', 'then' etc as you claim
> most are wrt new symbology.

This would be true, except that Python ALREADY REQUIRES familiarity with
the concepts denoted by the 'if' and 'else' keywords.  This is actually
another argument against using constructs like 'x when C else y' which
require the importation of yet more English into Python.  It is not a
valid argument against reusing 'if' and 'else' as symbols within a ternary
expression, since this usage builds in a simple and obvious way on
knowledge that has already been gained by using these keywords in the
context of conditional statements.

> again I think there is a logic especially for left to right, top down
> readers. My logic says read left to right seems to imply evaluate left
> to right. The decision has to be made before evaluating the alternatives
> (modern speculative compilers notwithstanding).

I too prefer to read from left to right, and top to bottom.  'x if C else
y' DOES 'read' left to right.  A ternary expression takes three arguments,
and yields one -- the placement of the conditional argument might
reasonably appear in any position within a linear ordering of these
arguments.  However, very few syntactic forms clearly convey which
expression is selected if the conditional evaluates to false/true, and
this is the critically important piece of information that the syntax
ought to convey! -- 'x if C else y' does; 'x when C else y' does also.
C?x:y does not.  Placing a weak and ambiguous separator like ':' between
the trueExpr and the falseExpr tells the reader nothing about which is
which. Only prior knowledge of C will tell you.  And -- if you read or use
the ternary only rarely, this is one detail that is likely to be
forgotten, leading to either an incorrect reading of the code, or the
necessity of checking the language reference.  Both outcomes are
undesireable.

> I think your point about the ':' being confusing is possibly correct.

Well, I'm glad we agree on something :-)

--
Norman Petry