PEP 308: Pep Update

[Dave Brueck]

On Thu, 27 Feb 2003, Anders J. Munch wrote:

> "Sean Ross" <sross at connectmail.carleton.ca> wrote:
> >
> > "Lulu of the Lotus-Eaters" <mertz at gnosis.cx> wrote in message
> > news:mailman.1046332734.23329.python-.
> > >
> > > In every Python construct that exists now, a condition is stated BEFORE
> > > the actions that depend on it.
> > >
> >
> > Hi.
> > "Contrariwise", this is not true in 'every' Python construct:
> >
> >     seq = range(100)
> >     evensquares = [x*x for x in seq if not x%2]
> >
> > So, 'The ternary form "x if C else y" [does not break] this uniformity',
> > list comprehensions do.
>
> Yes.  And that makes list comprehensions the most confusing Python
> construct there is.  Not only doesn't it read left to right, it
> doesn't even read right to left either.

Yeah, to some they are confusing, but others (including me) find list
comps very readable. IMO strict LtoR or strict RtoL reading as a
requirement for conditional operators has been overemphasized.

When reading written text you don't actually read individual characters
left to right unless you're a beginning reader because you recognize the
grouping as a word. The same holds true with many phrases, and of code. If
anything, a non-strict LtoR reading order poses a _very_ small hurdle for
someone completely unfamiliar with the syntax, but after seeing it once or
twice it is understood as a phrase anyway, which is why IMO you aren't
bothered by list comp token order anymore:

> Now since I use list comp.s a lot, I've gotten used to it and it
> doesn't bother me anymore.

> It's ok for commonly-used syntax to be special, because once learned it
> isn't forgotten. But the rarer a construct is, the more conventional and
> boring its syntax and semantics should be - even at the cost of
> terneness and elegance.

Or, put another way, by looking at it it should be easy to figure out what
it does. If you're unfamiliar with it and have to slow down when reading
the code and break it apart, your first guess as to what it does should be
correct. That's why I like the pseudocode-ish versions of the PEP
(keyword-based) as opposed to the special-syntax ones.

> > +1 "x if C else y"
>
> Had I expected conditional expressions to be used a lot, I might have
> liked that too.

I like it either way, because even if you're not familiar with the
construct it's easy to figure out what the meaning is. In the above usage
'if' and 'else' mean the same thing they do in other contexts, so it's
very likely that if you don't know what it does but take a guess you'll
probably be right.

-Dave