For review: PEP 308 - If-then-else expression

[Paul Moore]

aahz at pythoncraft.com (Aahz) writes:

> In article <r8ahfto4.fsf at morpheus.demon.co.uk>,
> Paul Moore  <gustav at morpheus.demon.co.uk> wrote:
>>
>>As a follow-on question - does anyone seriously feel that a
>>significant portion of c.l.p is likely to have its opinion swayed by
>>arguments made in this thread?
>
> Not by arguments, no, but by ideas. I believe that the swing voters
> are those who are mildly sympathetic to conditional expressions, but
> who find one or all of the various proposals abhorrent.

As a no voter, I'd say that applies to at least some of us, too. I'd
classify myself as unsympathetic in general (but not strongly - maybe
a bit more than "mildly"). However, every proposed syntax I have seen
strikes me as dreadful - I get the impression that they all come from
the "conditional expressions at any cost" mindset.

> If someone can come up with a truly Pythonic idiom for conditional
> expressions, I believe it'll pass.  I suspect that my criteria are
> similar to many other people's:
>
> * must have clear left-to-right or right-to-left meaning
>
> * must look vaguely readable even when abused as the conditional for if
> statements

My criteria are similar, but probably include a lot of extra provisos
that I can't quantify. And there's a *huge* component of "gut
instinct", which I have no hope of articulating.

But of course, the suggested voting procedure is going to destroy any
chance of something like this happening, isn't it? The first vote is
yes/no on having *anything* which will instantly polarise things. I
don't know how many people will say no because they fear a truly ugly
syntax getting accepted at stage 2, nor do I know how many people will
say yes in the hope that someone will come up with a nice idea for
syntax.

I think you've persuaded me that the only meaningful process (in the
sense of having a chance of having the people who lose accept their
defeat) is to have a vote on a specific proposed syntax. That syntax
needs to be agreed *before* the vote. I'd suggest you have a 2-stage
process:

1. Reach a conclusion on a syntax to put into PEP 308. This debate
   must have a very hard deadline imposed, or we never get
   anywhere. The agreed syntax becomes the official position of PEP
   308, and all other proposals are included in the PEP and noted as
   "rejected by the community". If no clear winner can be achieved,
   PEP 308 remains as it stands (with Guido's "expr if cond else expr"
   syntax), and *all* the proposed syntaxes are put in the PEP and
   noted as rejected by the community.

2. Vote on the (possibly modified) PEP 308. A simple yes/no
   vote. Tally the counts and hand them to Guido. (If you want to
   summarise them as yes/no/undecided, then set required majority
   levels, but to some extent that's just another chance for people to
   complain).

To some extent, anything else doesn't match the oficial PEP process
(where the PEP is modified to match the proposed solution, and then
the PEP is accepted or rejected once it's finalised and ready for a
decision). The only difference is that a community vote takes the
place of a BDFL pronouncement (at least until Guido decides he doesn't
agree with us :-))

Paul.
-- 
This signature intentionally left blank