[Python-Dev] accumulator display syntax

[Alex Martelli]

On Thursday 16 October 2003 02:31 pm, Michael Chermside wrote:
> Alex Martelli writes:
> > I think we could extend indexing to mean something different when
> > the [ ] contain a 'for', just like we extended list display to mean
> > something different (list comprehension) when the [ ] contain a
> > 'for'.  Syntax such as:
> >
> >     Top(10)[ humor(joke) for joke in jokes ]
> >
> > does not suggest a list is _returned_, just like foo[23] doesn't.
>
> I find the syntax a bit confusing.
>
> Are we subscripting here, or are we juxtaposing one expression
> ("Top(10)"), with a list comprehension ("[humor(joke) for joke in jokes]")?

"Subscripting", just like we would do with, say,

    Top(10)[ humor(joke) and joke in jokes ]

This syntax, too, is a bit confusing -- because we rarely use indexing
right on the result of a function call -- but it's perfectly valid Python 
today.  If you dislike the syntax, nothing stops you from writing, today:

select_top_10 = Top(10)
select_top_10[ humor(joke) and joke in jokes ]

and similarly nothing will stop you, if something like this accumulator
display syntax is approved, from writing in the second statement

select_top_10[ humor(joke) for joke in jokes ]

and indeed some would consider this other for more readable.

I am not proposing any newfangled "juxtaposing" syntax, writing two
expressions right one after the other, which would have no precedent
in Python; just an extension of the syntax allowed within brackets in
indexing syntax (by analogy with that allowed today within brackets in list
comprehension / list display syntax) -- for the semantics, see my separate
post "accumulator display semantics".  (Both of my posts are commentary
on the proposal by Peter Norvig for a new accumulator display syntax
and semantics: this syntax looks good to me to avoid the objection that
Peter's proposed "[foo: x for x in bar]" ``looks like it should be returning
a list'' due to the square brackets and the similar objection against the
separately proposed iterator-comprehension syntax).


> Not totally unreadable, but it rubs me the wrong way. I read [] used
> for subscripting as completely different from [] used for list literals
> and list comprehensions. They just happen to share the same pair of
> symbols. To me, this confuses the two somewhat.

Not long ago, what could go inside those square brackets was an
expression, period -- no matter whether the brackets stood on their
own (list display) or followed an expression (indexing/slicing).  Some
minor differences, of course, such as empty [ ] being valid only in
list display but syntactically invalid in indexing, and slice notation [a:b]
being valid in indexing but syntactically invalid in list display; but typical
uses such as [a,b,c] overlapping -- with different meanings, of course
(indexing X[a,b,c] -> the tuple (a,b,c) used as key; display [a,b,c] ->
creating a 3-items list).  So, different semantics but very similar syntax.

Then list comprehensions were introduced and the syntax admitted
inside [ ] got far wider, in "list display" cases only.  Why would it be
a problem if now the syntax admitted in the "similar syntax, different
semantics" case of "indexing" got similarly wider?  How would it
infringe on the "completely different ... just happen to share the same
pair of symbols" (and a lot about the syntax relating to what can
go inside those symbols, too) perception, which seems to me to be
pretty accurate?


Alex