[Python-Dev] Python Language Reference has no mention of list comÃprehensions

[Andrew Barnert]

On Dec 3, 2015, at 17:25, Steven D'Aprano <steve at pearwood.info> wrote:
> 
> On Thu, Dec 03, 2015 at 09:25:53AM -0800, Andrew Barnert via Python-Dev wrote:
>>> On Dec 3, 2015, at 08:15, MRAB <python at mrabarnett.plus.com> wrote:
>>> 
>>>>> On 2015-12-03 15:09, Random832 wrote:
>>>>> On 2015-12-03, Laura Creighton <lac at openend.se> wrote:
>>>>> Who came up with the word 'display' and what does it have going for
>>>>> it that I have missed?  Right now I think its chief virtue is that
>>>>> it is a meaningless noun.  (But not meaningless enough, as I
>>>>> associate displays with output, not construction).
> 
> I completely agree with Laura here -- to me "display" means output, not 
> construction, no matter what the functional programming community says 
> :-) but I suppose the connection is that you can construct a list using
> the same syntax used to display that list: [1, 2, 3] say.
> 
> I don't think the term "display" will ever feel natural to me, but I 
> have got used to it.
> 
> 
> Random832 wrote:
> 
>>>> In a recent discussion it seemed like people mainly use it
>>>> because they don't like using "literal" for things other than
>>>> single token constants.  In most other languages' contexts the
>>>> equivalent thing would be called a literal.
> 
> I'm not sure where you get "most" other languages from. At the very 
> least, I'd want to see a language survey. I did a *very* fast one (an 
> entire three languages *wink*) and found these results:
> 
> The equivalent of a list [1, a, func(), x+y] is called:
> 
> "display" (Python)
> 
> "literal" (Ruby)
> 
> "constructor" (Lua)
> 
> http://ruby-doc.org/core-2.1.1/doc/syntax/literals_rdoc.html#label-Arrays
> http://www.lua.org/manual/5.1/manual.html
> 
> Of the three, I think Lua's terminology is least worst.
> 
> 
> MRAB:
>>> "Literals" also tend to be constants, or be constructed out of
>>> constants.
> 
> Andrew: 
>> I've seen people saying that before, but I don't know where they get 
>> that. It's certainly not the way, say, C++ or JavaScript use the term.
> 
> I wouldn't take either of those two languages as examples of best 
> practices in language design :-)

No, but they seem to be the languages (along with C and Java) that people usually appeal to.

You also found "literal" used the same way as JavaScript in Ruby, one of three languages in your quick survey. It's also used similarly in ML and Haskell. In Lisp, it has a completely different meaning (a quoted list). 

But as I said before, we can't use the word "literal" to contrast with comprehensions, because a large segment of the Python community (including you) would find that use of the word confusing and/or annoying because you intuitively think of the C/FORTRAN/etc. definition rather than the C++/Ruby/JS/Haskell definition. It doesn't matter whether that's a peculiar quirk of the Python community or not, whether there's a good reason for it or not, etc.; all that matters is that it's true.

> [...]
>>> A list comprehension can contain functions, etc.
>> 
>> A non-comprehension display can include function calls, lambdas, or 
>> any other kind of expression, just as easily as a comprehension can. 
>> Is [1, x, f(y), lambda z: w+z] a literal? If so, why isn't [i*x for i 
>> in y] a literal?
> 
> I wouldn't call either a literal.

My point was that if the reason comprehensions aren't literals but the other kind of displays are is that the former can contain functions and the latter can't, that reason is just wrong. Both can contain functions. The intuition MRAB was appealing to doesn't even match his intuition, much less a universal one. And my sentence that you quoted directly below directly follows from that:

>> The problem is that we need a word that distinguishes the former; 
>> trying to press "literal" into service to help the distinction doesn't 
>> help.
>> 
>> At some point, Python distinguished between displays and 
>> comprehensions; I'm assuming someone realized there's no principled 
>> sense in which a comprehension isn't also a display, and now we're 
>> stuck with no word again.
> 
> I don't think comprehensions are displays.

Well, the reference docs say they are. (See 6.2.4 and following.) And I don't think the word "display" is used in the tutorial, glossary, etc.; the only place it's used, it explicitly includes comprehensions, calls them a "flavor" of displays, etc.

In fact, that's exactly why this issue came up: it's because comprehensions are a subset of displays that they don't have their own section you can look up in the docs.

And, as I explained before, Python's definition matches with the mathematical terms, and the terms in Miranda (which is probably the language we ultimately got them from).

> They certainly look 
> different, both in input form and output form:
> 
> py> [1, 2, 4, 8, 16]  # Display.
> [1, 2, 4, 8, 16]
> py> [2**n for n in range(5)]  # Comprehension.
> [1, 2, 4, 8, 16]
> 
> 
> Lists display using display syntax, not comprehension syntax.

Well, yes, because lists are stored extensionally, and therefore the only possible way to represent what's stored is extensionally. But in source code, where we're representing what's stored in the coder's head rather than in the interpreter's object heap, that's not a problem, so the coder can display them either way.

> Obviously 
> the list you get (the value of the object) is the same whichever syntax 
> you use, but the syntax is quite different.

Yes, the syntax for a list display is brackets around either an expression list or a comprehension clause. Just like the syntax for an if statement and a def statement are also quite different, but they're both still statements.

You can argue that you don't like that or don't find it intuitive or whatever, but you can't just choose to use the words in a way contrary to their actual definition and pretend you're clearing things up. Unless you have a time machine and can retroactively change Python 2.5 and 3.0.