Home Original page

PEP-308 a "simplicity-first" alternative

Paul Paterson hamonlypaulpaterson at houston.rr.com
Tue Feb 11 23:56:28 EST 2003 
"Erik Max Francis" <max at alcyone.com> wrote in message
news:3E49C041.C196ADAA at alcyone.com...
> Paul Paterson wrote:
> >
> > "Christian Tismer" <tismer at tismer.com> wrote in message
> > news:mailman.1045015194.30601.python-list at python.org...
> > >
> > > Anyway, please show me any other proposal that is
> > > as minimalistic as this one. Please, stare at it
> > > a little while and weight it's impact to the simplicity
> > > of the language, readability, ease of impl, and getting
> > > all these threads to a happy shut-down (or -up).
> >
> > I still like the minimalism of,
> >
> > x or y if C
>
> Err, do you mean `x or y if C' or `y or x if C'?  When you first
> suggested it (yes, it's in my list of unseconded proposals), you had it
> the other way round (mind the wrap):

You are correct, I did spell the x and y differently, but more below...

> This suffers exactly the same drawbacks as the `C and x else y'
> proposition, as well as foisting a completely _different_ order of
> evaluation than any other (as far as I can see) proposal.  `x if C else
> y' was mainly contentious because it was not left-to-right or
> right-to-left; this is similar neither (your original proposal seemed to
> be suggesting the right-to-left form).

The form above is spelt slightly different to most because the C is the
reverse of most other spellings. In most spellings,

x if C else y   # x is the norm and is selected if C is true

In my form above, x is still the norm (in cases where that has a meaning)
but the condition, C, selects the abnormal case, y.

Here's my logic,

1. The most common case of reading code is to get the overall meaning (hence
the normal case goes first).
2. When reading the code to see why the alternate path is taken you are
interested in the cause for the alternate path (so the alternate path
condition is stated in the +ve and goes at the end of the line, where it is
visible)
3. When reading code to see the possible paths/values you want to see the
alternative values close together (hence the "x or y" bit)

Point 2 above is very interesting to me. Consider the classic example of
sqrt...

A:   val = sqrt(x) if x>0 or "imag"
B:   val = sqrt(x) or "imag" if x<0

Now when I read these bits of code I think, "ok, val is getting set to
sqrt(x). Wait, things are more complex, val might get set to something else.
Why is this being done?". Now in form A (and analogous ones) I see the
condition (x>0) and in order to see the problem being avoided I have to
invert the condition ("ah, if x<0 then the sqrt will blow up), whereas in
form B, the condition is already in the right form to see the cases you want
to avoid.

I guess what I am asserting is that conditionals are usually used to select
an alternate value when the normal value wont work for some reason. The most
common question you have when reading the code is, "what is the reason". In
the A form, I have the additional burden of reversing the condition to get
at the reason.

In my view, almost all conditional forms are easy to write and easy to think
of while you write. The big difference between forms is how they seem when
you read then from the 3 different perspectives above.  Yes, this form is
the reverse of most other suggestions (although it parallels the selection
pattern, (x, y)[index]) but that doesn't matter in and of itself since only
one form at most will ever be implemented.

> Is every permutation of the ordering going to be tride in one or another
> of the proposals?  So far we've seen at least half of them.  :-)

I would think we will see them all by the end ;)
More information about the Python-list mailing list