PEP-308 a "simplicity-first" alternative

[Bengt Richter]

On Wed, 12 Feb 2003 20:48:10 -0800, Erik Max Francis <max at alcyone.com> wrote:

>Bengt Richter wrote:
>
>> Why do you quote the bad old hack and leave out the better alternative
>> I was proposing, and which was the point?
>
>Because I have addressed that alternative.  Not only do I not believe
>that it is not better, I believe that it is worse.  It is _more_
>idiomatic and _less_ readable.
>
>> Are you saying that
>> 
>>     x and {y} or {z}
>> 
>> is not readable, assuming you're familiar with the old idiom?
>> Newbie-obvious no, but how long would it take you to learn to use it?
>
>People already have the (actually correct) idioms like
>
>	(C and [x] or [y])[0]
>	(C and lambda: x or lambda: y)()
>
>As far as I know, nobody considers those good solutions; they are
I don't consider them good either, in case you misunderstood that part ;-)

>totally incomprehensible unless you already understand the whole sordid
>issue with the and/or syntax and why it doesn't work.  The purpose of a
>conditional operator is for it to be readable.  These two solutions are
>not readable.
Not readable enough ;-)

>
>Your solution is going from a broken and unreadable idiom and attempting
>to make it unbroken.  That is totally the wrong approach of good
>language design; you may make it unbroken, but it's damn sure still
>unreadable.
I hear you. I was just trying to propose a 2-character "fix" to what has
been in use. Does the BDFL plan to deprecate "and" and "or" then?

>
>You're talking about "assume you're familiar with the old idiom" as if
>that were a positive trait.  Nobody _likes_ the old idiom -- that's the
>whole point here.  It's unreadable and lends no hint as to what is meant
>by it.
Somebody liked it well enough to create it ;-)

>
>> Especially since you could just use it, and ignore fine points
>> about what would happen if a bare y was logically a false value.
>
>So can you rigorously define the behavior of an expression with {}
>markers in the general case?  Can you even rigorously define it here? 
I think so.

>What happens when it appears somewhere other than one of the operands to
>a logical operator, what then?  Can you even fully define its semantics?
Sure, in those contexts it will act like "(True and {x})"

>
>You're patching up a broken, ugly idiom with a complicated,
>hard-to-explain syntax that will only make the broken idiom more
>idiomatic.  It makes it no longer broken, but it makes it less readable.
>
>> Is this really cleaner?
>> 
>>    (if x: y else: z)
>
>Yes, I think it is.  It's clear and easily understandable even to
>someone who's never seen it before.  It's light-years ahead of any
>solution I've seen based on patching up the unreadable and/or hack.
I take it think that Python's and/or semantics was a design mistake.
Perhaps so ;-)

Regards,
Bengt Richter