PEP 308: Pep Update

Robin Becker robin at jessikat.fsnet.co.uk
Thu Feb 27 15:07:07 EST 2003


In article <pan.2003.02.27.18.27.27.852914 at canada.com>, Norman Petry
<npetry1 at canada.com> writes
>On Thu, 27 Feb 2003 09:23:09 +0000, Robin Becker wrote:
>
......
>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.
>

mathematics is also learned. The students presumably know some 'natural'
language so they should learn to use 'add' not '+' when learning math?

This is a poor argument. So the students have some maths but not a lot

when I see

    /
    |  y>3: 0
x = |
    |  y<=3: 2
    \

in a math text I don't have a great deal of trouble with it despite
being an engineer :) (of course if the \/ chars were interchanged I
should be reaching for my integrator raygun)

>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!
>
early adopters get to form the language, if there are many C/C++
programmers who use python surely they should influence the way the
language develops.

.
.....
>This would be true, except that Python ALREADY REQUIRES familiarity with
>the concepts denoted by the 'if' and 'else' keywords.  This is actually
..... not if you're learning it. The teaching argument is used one place
and discarded another. My former colleague Chi Wai programmed C and
Pascal without understanding or being able to read English. He looked at
the symbols 'if' 'while' etc as though they were ideograms. Semantic
familiarity is not required.

>> 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,
......

I agree we can say the words and get the meaning in many orders. The
trouble is that Python is not side effect free. I don't see these things
spelled out in Python, but simple is better than complex. If all
statements were strict top down left right evaluating, that would make a
simple way to explain the order in which things get evaluated. Of course
if you demand that all the expressions are to be evaluated then any
order will do, but I feel that only two of the three should be. Given
that the condition must precede in logical evaluation the expression and
my directional bias makes me want the condition lexically first. I have
no objection at all to

        (if C then x else y)

but others may want to spell it tersely (C?x:y) which is what
specialists always end up doing. 

Of course as others point out Python already is broken in the left right
rule so it becomes harder to argue about side effects etc. I know this
is a poor argument, but it has some merit.

I see nothing weak about ':'.

There is a widely used verbose language called COBOL which uses lot's of
English like words. I think Zope in COBOL would be a formidable
achievement, Zope in mostly Python is doable because of its expressivity
which is in part due to curtness.

If we base everything on a 12 year old's understanding/ability we'll get
a dumbed down language which is unsuitable for serious programming.

>
>> I think your point about the ':' being confusing is possibly correct.
>
>Well, I'm glad we agree on something :-)
>
>--
>Norman Petry

-- 
Robin Becker




More information about the Python-list mailing list