PEP 308: Discussion Summary

Raymond Hettinger vze4rx4y at
Wed Feb 19 03:05:27 CET 2003

Here is a recap of the discussion over the last few days:

* Someone re-proposed c ? a else b.  The rationale is that the ?
   is a better marker than "then" and is suggestive enough to not
   need a leading "if".  It doesn't require a new keyword and does
   not overload the colon.  No one shot this down but it didn't
   generate strong support either.

* There was an interesting, but fruitless discussion on how
   "c then a else b" could be implemented as a pair of binary
    operators which could also have standalone semantics.

* There was a rapidly shot down idea to use bool.choose(a, b) where
   choose() was a special method that could somehow implement
   lazy evaluation of its arguments.

*  A recent proposal is: (? <cond1>: <expr1>, <cond2>: <expr2>, <default>
   There have only been a few hours for comment.  Though the
   visual cues are there, my first thought is that the colon usage is
   likely to confuse anyone already exposed to the c?a:b form in
   other languages where the colon separates the alteratives rather
   than the condition and alternative.

Here is a recap of the results of everyone's ad-hoc, non-scientific
usability tests on their friends, relatives, and employees:

* In general, all of the forms were decipherable by people who already
   knew Python.

* The c?a:b form was understandable to people familiar
   with other languages.  With a single example, others were able
   to understand the form and found it easy to use.  The surprise
   was that the n-ary form (using parens for sub-expressions)
   managed to confuse even non-beginners.  A possible
   cause is that the grouping and precedence cues for parentheses
   do not mix well with the concepts of grouping by ternary operator
   and of short-circuit evaluation.

* The (if c: a else: b) form stumped some of the respondants.
   In some experiments, this was especially surprising because
   they had just seen one of the other forms and had some expectation
   of what it was supposed to do.  The root problem appears to be
   the blurring of the line between statements and expressions where
   the keyword and colon cues proved misleading.  On the plus side,
   everyone who understood the ternary version had no problem with
   the n-ary version.

* The "c then a else b" form was understood by most though a few
   thought it looked unnatural in longer expressions.  There were some
   who understood it but could not make the jump to the n-ary form
   (using the elif keyword).  It appears that the colons help to visually
   parse the n-ary form.

Since thread activity has dropped considerably, voting will
take place soon but not earlier than Friday.

Raymond Hettinger

More information about the Python-list mailing list