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

[MRAB]

On 2015-12-04 01:25, Steven D'Aprano 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 :-)
>
> "Literal" in computing has usually meant something like MRAB's sense
> for close on 20 years, at least. This definition is from FOLDOC (Free
> On-Line Dictionary Of Computing), dated 1996-01-23:
>
> literal
>
>     <programming> A constant made available to a process, by
>     inclusion in the executable text.  Most modern systems do not
>     allow texts to modify themselves during execution, so literals
>     are indeed constant; their value is written at compile-time
>     and is read-only at run time.
>
>     In contrast, values placed in variables or files and accessed
>     by the process via a symbolic name, can be changed during
>     execution.  This may be an asset.  For example, messages can
>     be given in a choice of languages by placing the translation
>     in a file.
>
>     Literals are used when such modification is not desired.  The
>     name of the file mentioned above (not its content), or a
>     physical constant such as 3.14159, might be coded as a
>     literal.  Literals can be accessed quickly, a potential
>     advantage of their use.
>
>
> I think that an important factor is that "literal" is a description of
> something in source code, like "expression" and "declaration". We surely
> don't want a distinction between the *values* x and y below:
>
> x = 3.14159
>
> y = 4.0 - len("a")
> y += 0.14159
>
> but we might want to distinguish between the way they are constructed: x
> is constructed from a literal, y is not.
>
>
> [...]
>> > 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.
>
> I often find myself (mis)using the term "literal" to describe
> constructing a list using a display where each item is itself a literal:
>
> x = [1, 2, 3]
>
Where there can be a grey area is in those languages where strings are
mutable: you can assign a string literal to a variable and then mutate
it.

In that case, there's copying going on, either on the assignment or on
the modification (copy on write, more efficient than always copying
when, say, passing it into a function).

> (or at least something which *could* have been a literal, if Python's
> parsing rules were just a tiny bit different, like -1 or 2+3j) but I
> accept that's an abuse of the term. But I certainly wouldn't use the
> term to describe a list constructed from non-literal parts:
>
> x = [a, b**2, func() or None]
>
> and absolutely not for a list comprehension.
>
>
>> 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. 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. Obviously
> the list you get (the value of the object) is the same whichever syntax
> you use, but the syntax is quite different.
>
>
> [...]
>> Ultimately, the best we have is "displays that aren't comprehensions"
>> or "constructions that aren't comprehensions".
>
> I don't think that's right. We can easily distinguish a display from a
> comprehension:
>
> - displays use the comma-separated item syntax [1, 2, 3], the same
> syntax used for output;
>
> - comprehensions use a variation on "set builder" syntax from
> mathematics, using for-loop syntax [expr for x in seq].
>
> I don't see any good reason for maintaining that there's just one
> syntax, "display", which comes in two forms: a comma-separated set of
> values, or a for-loop. The only thing they have in common (syntax-wise)
> is that they both use [ ] as delimiters. They look different, they
> behave differently, and only one matches what the list actually displays
> as. Why use one term for what is clearly two distinct (if related)
> syntaxes?
>