PEP 308: Results of "Helping Aahz set up the ballot"

Michael Chermside mcherm at destiny.com
Sat Feb 22 03:24:48 CET 2003


Aahz:

As you probably saw in a thread bearing your name, I took a
quick simple poll (of those still bothering to follow the
PEP 308 discussion). My reason for performing the poll was
that I was seeing so many syntaxes discussed that I thought
the key ideas were being burried in a wash of syntax options.

I had 19 people casting votes, with the following results:
(see 
<http://mail.python.org/pipermail/python-list/2003-February/148907.html>
for interpretation of the syntax numbers):

Syntax  # votes
   11      12        x if C else y
   14      10        C ? x : y
   12       8        if C then x else y
   13       8        if C: x else: y
   18       7        C ?? x || y
   22       6        C ? x else y
   21       5        x when C else y

Syntax  # votes       Syntax  # votes
   16       3            15       1
   23       2            17       1
   24       2            26       1
   25       2            27       1
   28       2            31       1
   38       2            34       1
   39       2            36       1
                         40       1

You are welcome to do whatever you like with this information
(including ignoring it completely), bearing in mind that it is
not particularly . My own interpretation is simply that the
"x if C else y" syntax (Guido's original) and "C ? x : y" (C
syntax) both have a lot of support and should probably not be
ignored (though either could certainly be intentionally
*rejected*).

Anyway, good luck with setting up the vote... I hope it goes
smoothly. One final note: at the bottom of this email I have
included all comments I received. Again, feel free to use them
or ignore them as you like.

-- Michael Chermside

------------------------------------------------
I think reading left-to-right is very important.
------------------------------------------------
Please, include

ifelse(C, :x, :y)

- this form will be possible anyway if PEP 312 is to succeed ;-)
------------------------------------------------
   - I don't think it's obviously way too many options, if we
     go for some more or less approval-voting-like scheme.
     It's too many to try to put a ranking on, but not too
     many to say good/bad/indifferent to.

   - I suspect that if you declare that such-and-such syntaxes
     are too unpopular to be worth bothering with, then the
     small minorities who like those syntaxes will be convinced
     that you've rigged it. So doing this by private mail may
     not work.

   - I think the following are too weird to be worth taking
     seriously, which is not the same as having too little
     support to take them seriously:

       16 (looks like a function but isn't one; nothing to
           differentiate the three arguments at first glance)
       18 (bizarrely ungrammatical, looks like a syntax error)

       24 (looks like it's doing something very different to
           what it's actually doing)
       27 (angle brackets are, I'm afraid, just not remotely Pythonic)
       28 (most of the drawbacks of the current and/or hack,
           without the advantage of being able to work out
           what it means from first principle)

       31 ("@"? WTF?)
       32 (might make sense for Forth aficionados, but I don't think
           they're a large part of the Python community)
       34 ("|" has a meaning already, and it ain't that)
       36 (as 24; actually I like 36 a bit more than I like 24)
       37 (confusing because it suggests that the relationship
           between C and x is the same as that between x and y;
           will confuse the hell out of people used to certain
           functional languages, though that's no big deal)
       38 (as 18)
       40 (unbearable)

   - my vote, in any case, is for leaving all the options on the ballot,
     with the possible exception of ones that were never popular and
     have been disowned even by their inventors.
------------------------------------------------
I hope the vote will permit preferences, this would avoid having to make 
a choice between close preferences.
------------------------------------------------






More information about the Python-list mailing list