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

[Nick Coghlan]

On 4 December 2015 at 12:48, Andrew Barnert via Python-Dev
 wrote:
> On Dec 3, 2015, at 17:25, Steven D'Aprano  wrote:
>> On Thu, Dec 03, 2015 at 09:25:53AM -0800, Andrew Barnert via Python-Dev 
>> wrote:
>>> 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'm one of the folks that use it that way, but I learned that
terminology *from* the Python language reference.

>> 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.

Even though it's true, I'm not sure it's sufficient to rule out a
switch to "there are two kinds of literal" as the preferred
terminology.

The recent case that comes to mind is the new format string literals -
those can include arbitrary subexpressions, like container displays
and comprehensions, but the conclusion from the PEP 498 discussion was
that it makes the most sense to still consider them a kind of string
literal.

There's also a relatively straightforward way of defining the key
semantic different between a literal and a normal constructor call:
with a literal, there's no way to override the type of the resulting
object, while a constructor call can be monkeypatched like any other
callable.

The distinction that arises for containers is then the one that Chris
Angelico pointed out: a container literal may have constant content,
*or* it may have dynamic content. If we switched from calling things
"displays" to calling them "dynamic literals", I'd be surprised if too
many folks that were able to figure out what "display" meant struggled
to make the transition.

Summarising that idea:

* literals: any of the dedicated expressions that produce an instance
of a builtin type
* constant literal: literals that produce a constant object that can
be cached in the bytecode
* dynamic literal: literals containing dynamic subexpressions that
can't be pre-calculated
* display: legacy term for a dynamic literal (originally inherited from ABC)
* comprehension: a dynamic literal that creates a new container from
an existing iterable
* lexical literal: constant literals and dynamic string literals [1]

The ast.literal_eval() docs would need a slight adjustment to refer to
"literals (excluding container comprehensions and generator
expressions)", rather than the current "literals and container
displays".

Regards,
Nick.

[1] https://docs.python.org/dev/reference/lexical_analysis.html#literals

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[R. David Murray]

On Fri, 04 Dec 2015 18:38:03 +1000, Nick Coghlan  wrote:
> Summarising that idea:
> 
> * literals: any of the dedicated expressions that produce an instance
> of a builtin type
> * constant literal: literals that produce a constant object that can
> be cached in the bytecode
> * dynamic literal: literals containing dynamic subexpressions that
> can't be pre-calculated
> * display: legacy term for a dynamic literal (originally inherited from ABC)
> * comprehension: a dynamic literal that creates a new container from
> an existing iterable
> * lexical literal: constant literals and dynamic string literals [1]
> 
> The ast.literal_eval() docs would need a slight adjustment to refer to
> "literals (excluding container comprehensions and generator
> expressions)", rather than the current "literals and container
> displays".

Except that that isn't accurate either:

>>> import ast
>>> ast.literal_eval('[1, id(1)]')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/rdmurray/python/p36/Lib/ast.py", line 84, in literal_eval
return _convert(node_or_string)
  File "/home/rdmurray/python/p36/Lib/ast.py", line 57, in _convert
return list(map(_convert, node.elts))
  File "/home/rdmurray/python/p36/Lib/ast.py", line 83, in _convert
raise ValueError('malformed node or string: ' + repr(node))
ValueError: malformed node or string: <_ast.Call object at 0xb73633ec>

So it's really container displays consisting of literals, which we could
call a "literal container display".

I think the intuitive notion of "literal" is "the value is literally
what is written here".  Which is a redundant statement; 'as written' is,
after all, what literally means when used correctly :).  That makes it
a language-agnostic concept if I'm correct.

I think we will find that f strings are called f expressions, not f literals.

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric Fahlgren]

David R. Murray wrote: 
> I think the intuitive notion of "literal" is "the value is literally what is 
> written
> here".  Which is a redundant statement; 'as written' is, after all, what 
> literally
> means when used correctly :).  That makes it a language-agnostic concept if 
> I'm
> correct.

So { x : 1 } is not literally a literal, it's figuratively a literal, or more 
simply a figurative.

Eric

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Andrew Barnert via Python-Dev]

On Dec 4, 2015, at 00:38, Nick Coghlan  wrote:
> 
> On 4 December 2015 at 12:48, Andrew Barnert via Python-Dev
>  wrote:
>> On Dec 3, 2015, at 17:25, Steven D'Aprano  wrote:
 On Thu, Dec 03, 2015 at 09:25:53AM -0800, Andrew Barnert via Python-Dev 
 wrote:
 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'm one of the folks that use it that way, but I learned that
> terminology *from* the Python language reference.

If that's the usual case, then isn't it almost certainly more true for 
"display" than for "literal"? I doubt most Python users came in with a 
pre-existing notion of "display" from another language, or from programming in 
general--or, if they did, it's probably one of the senses that's irrelevant 
enough to not confuse anyone (like a repr, or a string formatting template). So 
if you want to redefine one of our terms to allow a new distinction, why not 
that one?

More importantly, as I said in my other message: do we actually need to be able 
to make this distinction? The problem this thread set out to solve is that 
"comprehension" doesn't have a docs section because it's just a subset of 
displays, so you can't search for it. Making it a subset of dynamic literals, 
which is a subset of literals, seems like it gets us farther from a solution. 
Right now, we could easily change the section title to "list displays 
(including comprehensions)" and we're done.

>>> 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.
> 
> Even though it's true, I'm not sure it's sufficient to rule out a
> switch to "there are two kinds of literal" as the preferred
> terminology.
> 
> The recent case that comes to mind is the new format string literals -
> those can include arbitrary subexpressions, like container displays
> and comprehensions, but the conclusion from the PEP 498 discussion was
> that it makes the most sense to still consider them a kind of string
> literal.
> 
> There's also a relatively straightforward way of defining the key
> semantic different between a literal and a normal constructor call:
> with a literal, there's no way to override the type of the resulting
> object, while a constructor call can be monkeypatched like any other
> callable.

Is that an important distinction to anyone but people who write Python 
implementations? If some library I'm using chooses to monkeypatch or shadow a 
type name, the objects are still going to quack the way I expect (otherwise, 
I'm going to stop using that library pretty quickly). And meanwhile, why do I 
need to distinguish between libraries that monkeypatch the stdlib for me and 
libraries that install an import hook to patch my code?

It's certainly not meaningless or completely useless (e.g., the discussion 
about whether f-strings are literals would have been shorter, and had more of a 
point), but it doesn't seem useful enough to be worth redefining existing 
terminology.

> The distinction that arises for containers is then the one that Chris
> Angelico pointed out: a container literal may have constant content,
> *or* it may have dynamic content.

Well, yes, but, again, both forms of container literal can have dynamic 
content: [f(), g()] is just as dynamic as [x() for x in (f, g)]. So we still 
don't have the contrast we were looking for.

Also, [1, 2] is literal, and not dynamic, but it's not a constant value, so 
calling it a constant literal seems likely to be more confusing than helpful.

One more thing: we don't have to worry about whether def and class are literal 
constructs because they're not expressions, but what about lambda? It fits your 
definition of literal. JS calls them literals (Ruby is a bit confusing because 
it splits the notion of function into three entirely independent things), as do 
some functional languages. And this means you can write a function-table dict 
that's all literals. As for whether it's constant--the code object obviously 
can be 

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

[Laura Creighton]

In a message of Thu, 03 Dec 2015 13:37:17 +, Paul Moore writes:
>On 3 December 2015 at 12:51, Laura Creighton  wrote:
>> Intentional or Oversight?
>
>Hard to find :-)
>
>https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries
>
>I went via "Atoms" in the expression section, then followed the links
>in the actual grammar spec.
>
>Paul

I think the whole use of the language displays as in
  
  6.2.4. Displays for lists, sets and dictionaries

  For constructing a list, a set or a dictionary Python provides 
  special syntax called “displays”, each of them in two flavors:

either the container contents are listed explicitly, or
they are computed via a set of looping and filtering instructions, 
called a comprehension.

is very odd.  I don't know anybody who talks of 'displays'.  They
talk of 'two ways to construct a'.  

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 think that 

6.2.4 Constructing lists, sets and dictionaries

would be a much more useful title, and

6.2.4 Constructing lists, sets and dictionaries -- explicitly or through 
the use of comprehensions

an even better one.

Am I missing something important about the 'display' language?

Laura
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Moore]

On 3 December 2015 at 12:51, Laura Creighton  wrote:
> Intentional or Oversight?

Hard to find :-)

https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries

I went via "Atoms" in the expression section, then followed the links
in the actual grammar spec.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[M.-A. Lemburg]

On 03.12.2015 17:09, Ryan Gonzalez wrote:
> 
> 
> On December 3, 2015 8:26:23 AM CST, Laura Creighton  wrote:
>> In a message of Thu, 03 Dec 2015 13:37:17 +, Paul Moore writes:
>>> On 3 December 2015 at 12:51, Laura Creighton  wrote:
 Intentional or Oversight?
>>>
>>> Hard to find :-)
>>>
>>> https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries
>>>
>>> I went via "Atoms" in the expression section, then followed the links
>>> in the actual grammar spec.
>>>
>>> Paul
>>
>> I think the whole use of the language displays as in
>>  
>>  6.2.4. Displays for lists, sets and dictionaries
>>
>>  For constructing a list, a set or a dictionary Python provides 
>>  special syntax called “displays”, each of them in two flavors:
>>
>>either the container contents are listed explicitly, or
>>they are computed via a set of looping and filtering instructions, 
>>called a comprehension.
>>
>> is very odd.  I don't know anybody who talks of 'displays'.  They
>> talk of 'two ways to construct a'.  
>>
>> 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 think that 
>>
>>6.2.4 Constructing lists, sets and dictionaries
>>
>> would be a much more useful title, and
>>
>> 6.2.4 Constructing lists, sets and dictionaries -- explicitly or
>> through the use of comprehensions
>>
> 
> What about:
> 
> 6.2.4 Constricting lists, sets, and dictionaries (including comprehensions)
> 
> or something to that effect?
> 
>> an even better one.
>>
>> Am I missing something important about the 'display' language?

I don't think changing a single header is useful in this case.

The grammar uses the token term "display" to mean "representation
of an object". While you normally only think of output when talking
of the representation of an object, it can also refer to the visual
definition of an object when passed to the parser.

A list comprehension is an example of such a visual definition of
an object, hence the token name.

If we were to change the term, we'd have to change it throughout
the reference, grammar and parser implementation.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Dec 03 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stephen J. Turnbull]

Laura Creighton writes:

 > Am I missing something important about the 'display' language?

A display is a constructor that looks like a literal but isn't.  It is
syntactically like the printed output, but may contain expressions to
be evaluated at runtime as well as compile-time constant expressions
that can be "folded".  I find it useful to have a single word that
means that, and can't think of a better one.  I suppose "display" was
chosen because the syntax is intended to "look like" the constructed
object (ie, its printable representation).  A comprehension
corresponds to what is often called "set-builder notation" for sets;
it doesn't look like the print representation.  I'd be perfectly happy
to include comprehensions in the concept of display, but Guido says
no, and I'm happy to have them be different too. :-)

I don't know if you missed any of that, I don't claim that it's
terribly important, and Your Mileage May Vary, but it works for me. :-)

BTW, I don't care if usage is consistent in this case.  I like
consistency, but insisting on it here would be an Emersonian hobgoblin
IMO (again, YMMV).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[M.-A. Lemburg]

On 03.12.2015 18:30, Laura Creighton wrote:
> What I would like is if it were a lot easier for a person who just
> saw a list comprehension for the very first time, and was told what it
> is, to have a much, much easier time finding it in the Reference Manual.

Such a person should more likely be directed to the tutorial
rather than the very technical language spec :-)

> Would a section on comprehensions in general, defining what a comprehension
> is be appropriate?

We already have this in the tutorial:

https://docs.python.org/3/tutorial/datastructures.html#list-comprehensions

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Dec 03 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Moore]

On 3 December 2015 at 14:26, Laura Creighton  wrote:
> Am I missing something important about the 'display' language?

It's a term that's used in the lisp and/or functional programming
communities, I believe. And I think I recollect that something similar
is used in (mathematical) set theory So it's not completely an
invented term.

But that's not to say it's particularly obvious in this context...
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

I borrowed 'display' from the formal definition of ABC. It's still used in
the quick reference: http://homepages.cwi.nl/~steven/abc/qr.html#EXPRESSIONS
. I hadn't heard it before and didn't think to research its heritage. I
like it for list/set/dict displays since it's rather a stretch to call
those literals (they can contain expressions after all). I don't think of a
comprehension as a display though (even though it's syntactically related).

On Thu, Dec 3, 2015 at 9:04 AM, Paul Moore  wrote:

> On 3 December 2015 at 14:26, Laura Creighton  wrote:
> > Am I missing something important about the 'display' language?
>
> It's a term that's used in the lisp and/or functional programming
> communities, I believe. And I think I recollect that something similar
> is used in (mathematical) set theory So it's not completely an
> invented term.
>
> But that's not to say it's particularly obvious in this context...
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Laura Creighton]

What I would like is if it were a lot easier for a person who just
saw a list comprehension for the very first time, and was told what it
is, to have a much, much easier time finding it in the Reference Manual.

Would a section on comprehensions in general, defining what a comprehension
is be appropriate?

Laura

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[R. David Murray]

On Thu, 03 Dec 2015 16:15:30 +, MRAB  wrote:
> On 2015-12-03 15:09, Random832 wrote:
> > On 2015-12-03, Laura Creighton  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).
> >
> > 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.
> >
> "Literals" also tend to be constants, or be constructed out of
> constants.
> 
> A list comprehension can contain functions, etc.

Actually, it looks like Random832 is right.  The docs for
ast.literal_eval say "a Python literal or container display".

Which also means we are using the term 'display' inconsistently,
since literal_eval will not eval a comprehension.

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Andrew Barnert via Python-Dev]

> On Dec 3, 2015, at 08:15, MRAB  wrote:
> 
>>> On 2015-12-03 15:09, Random832 wrote:
>>> On 2015-12-03, Laura Creighton  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).
>> 
>> 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.
> "Literals" also tend to be constants, or be constructed out of
> constants.

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. But I don't see any 
point in arguing about it if people just accept that "literal" is too broad a 
term to capture any useful intuition here. 

> 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?

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 think that
>>> 
>>>6.2.4 Constructing lists, sets and dictionaries
>>> 
>>> would be a much more useful title, and
>>> 
>>>6.2.4 Constructing lists, sets and dictionaries -- explicitly or through 
>>> the use of comprehensions
>> 
>> I don't like the idea of calling it "explicit construction".
>> Explicit construction to me means the actual use of a call to the
>> constructor function.

Agreed.

The obvious mathematical terms are "extension" and "intention", but I get the 
feeling nobody would go for that.

Ultimately, the best we have is "displays that aren't comprehensions" or 
"constructions that aren't comprehensions".

Which means that something like "list, set, and dictionary displays (including 
comprehensions)" is about as good as you can make it without inventing a new 
term. There's nothing to contrast comprehensions with.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

On December 3, 2015 10:09:56 AM CST, Ryan Gonzalez  wrote:
>
>
>On December 3, 2015 8:26:23 AM CST, Laura Creighton 
>wrote:
>>In a message of Thu, 03 Dec 2015 13:37:17 +, Paul Moore writes:
>>>On 3 December 2015 at 12:51, Laura Creighton  wrote:
 Intentional or Oversight?
>>>
>>>Hard to find :-)
>>>
>>>https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries
>>>
>>>I went via "Atoms" in the expression section, then followed the links
>>>in the actual grammar spec.
>>>
>>>Paul
>>
>>I think the whole use of the language displays as in
>>  
>>  6.2.4. Displays for lists, sets and dictionaries
>>
>>  For constructing a list, a set or a dictionary Python provides 
>>  special syntax called “displays”, each of them in two flavors:
>>
>>either the container contents are listed explicitly, or
>>they are computed via a set of looping and filtering instructions,
>
>>called a comprehension.
>>
>>is very odd.  I don't know anybody who talks of 'displays'.  They
>>talk of 'two ways to construct a'.  
>>
>>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 think that 
>>
>>6.2.4 Constructing lists, sets and dictionaries
>>
>>would be a much more useful title, and
>>
>>6.2.4 Constructing lists, sets and dictionaries -- explicitly or
>>through the use of comprehensions
>>
>
>What about:
>
>6.2.4 Constricting lists, sets, and dictionaries (including
>comprehensions)
>

Whoops! I meant "Constructing", not "Constricting". Pythons definitely 
constrict their prey, but that's not what I was referring to...

>or something to that effect?
>
>>an even better one.
>>
>>Am I missing something important about the 'display' language?
>>
>>Laura
>>___
>>Python-Dev mailing list
>>Python-Dev@python.org
>>https://mail.python.org/mailman/listinfo/python-dev
>>Unsubscribe:
>>https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Random832]

On 2015-12-03, Laura Creighton  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).

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 think that 
>
> 6.2.4 Constructing lists, sets and dictionaries
>
> would be a much more useful title, and
>
> 6.2.4 Constructing lists, sets and dictionaries -- explicitly or through 
> the use of comprehensions

I don't like the idea of calling it "explicit construction".
Explicit construction to me means the actual use of a call to the
constructor function.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[MRAB]

On 2015-12-03 15:09, Random832 wrote:

On 2015-12-03, Laura Creighton  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).


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.


"Literals" also tend to be constants, or be constructed out of
constants.

A list comprehension can contain functions, etc.


I think that

6.2.4 Constructing lists, sets and dictionaries

would be a much more useful title, and

6.2.4 Constructing lists, sets and dictionaries -- explicitly or through 
the use of comprehensions


I don't like the idea of calling it "explicit construction".
Explicit construction to me means the actual use of a call to the
constructor function.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Laura Creighton]

In a message of Thu, 03 Dec 2015 15:09:12 +, Random832 writes:

>> 6.2.4 Constructing lists, sets and dictionaries -- explicitly or through 
>> the use of comprehensions
>
>I don't like the idea of calling it "explicit construction".
>Explicit construction to me means the actual use of a call to the
>constructor function.

Would

 6.2.4 Creating lists, sets and dictionaries -- explicitly or through the 
use of comprehensions

get rid of that objection?

Laura
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ryan Gonzalez]

On December 3, 2015 8:26:23 AM CST, Laura Creighton  wrote:
>In a message of Thu, 03 Dec 2015 13:37:17 +, Paul Moore writes:
>>On 3 December 2015 at 12:51, Laura Creighton  wrote:
>>> Intentional or Oversight?
>>
>>Hard to find :-)
>>
>>https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries
>>
>>I went via "Atoms" in the expression section, then followed the links
>>in the actual grammar spec.
>>
>>Paul
>
>I think the whole use of the language displays as in
>  
>  6.2.4. Displays for lists, sets and dictionaries
>
>  For constructing a list, a set or a dictionary Python provides 
>  special syntax called “displays”, each of them in two flavors:
>
>either the container contents are listed explicitly, or
>they are computed via a set of looping and filtering instructions, 
>called a comprehension.
>
>is very odd.  I don't know anybody who talks of 'displays'.  They
>talk of 'two ways to construct a'.  
>
>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 think that 
>
>6.2.4 Constructing lists, sets and dictionaries
>
>would be a much more useful title, and
>
>6.2.4 Constructing lists, sets and dictionaries -- explicitly or
>through the use of comprehensions
>

What about:

6.2.4 Constricting lists, sets, and dictionaries (including comprehensions)

or something to that effect?

>an even better one.
>
>Am I missing something important about the 'display' language?
>
>Laura
>___
>Python-Dev mailing list
>Python-Dev@python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[M.-A. Lemburg]

On 03.12.2015 19:27, Laura Creighton wrote:
> So how do we get search to work so that people in the Language
> Reference who type in 'List Comprehension' get a hit?

It seems that the search index is broken for at least a few
documentation file releases:

ok: 
https://docs.python.org/2.6/search.html?q=comprehension_keywords=yes=default
not ok: 
https://docs.python.org/2.7/search.html?q=comprehension_keywords=yes=default
ok: 
https://docs.python.org/3.2/search.html?q=comprehension_keywords=yes=default
not ok: 
https://docs.python.org/3.3/search.html?q=comprehension_keywords=yes=default
not ok: 
https://docs.python.org/3.4/search.html?q=comprehension_keywords=yes=default
not ok: 
https://docs.python.org/3.5/search.html?q=comprehension_keywords=yes=default

(ok = "/reference/expressions.html is found")

Interestingly, these URLs give different results, e.g.

ok: 
https://docs.python.org/release/2.7.1/search.html?q=comprehension_keywords=yes=default
ok: 
https://docs.python.org/release/2.7.2/search.html?q=comprehension_keywords=yes=default
ok: 
https://docs.python.org/release/2.7.3/search.html?q=comprehension_keywords=yes=default
ok: 
https://docs.python.org/release/2.7.4/search.html?q=comprehension_keywords=yes=default
ok: 
https://docs.python.org/release/2.7.5/search.html?q=comprehension_keywords=yes=default
ok: 
https://docs.python.org/release/2.7.6/search.html?q=comprehension_keywords=yes=default
ok: 
https://docs.python.org/release/2.7.7/search.html?q=comprehension_keywords=yes=default
ok: 
https://docs.python.org/release/2.7.8/search.html?q=comprehension_keywords=yes=default
not ok:
https://docs.python.org/release/2.7.9/search.html?q=comprehension_keywords=yes=default
not ok:
https://docs.python.org/release/2.7.10/search.html?q=comprehension_keywords=yes=default

Looks like something changed between the 2.7.8 and 2.7.9 release.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Dec 03 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Laura Creighton]

So how do we get search to work so that people in the Language
Reference who type in 'List Comprehension' get a hit?

Laura

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

On Thu, Dec 03, 2015 at 09:25:53AM -0800, Andrew Barnert via Python-Dev wrote:
> > On Dec 3, 2015, at 08:15, MRAB  wrote:
> > 
> >>> On 2015-12-03 15:09, Random832 wrote:
> >>> On 2015-12-03, Laura Creighton  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

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]

(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 

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

[Chris Angelico]

On Fri, Dec 4, 2015 at 12:25 PM, Steven D'Aprano  wrote:
> 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?

You come across something syntactic that begins by opening a square
bracket, and you know that its semantics are: "construct a new list".
That's what's common here.

What goes *inside* those brackets can be one of two things:

1) A (possibly empty) comma-separated sequence of expressions

2) One or more nested 'for' loops, possibly guarded by 'if's, and a
single expression

So we have two subforms of the same basic syntax. The first one
corresponds better to the output format, in the same way that a string
literal might correspond to its repr under specific circumstances.
Neither is a literal. Neither is a call to a constructor function
(contrast "list()" or "list.__new__(list)", which do call a
constructor). So what is this shared syntax? Whatever word is used,
it's going to be a bit wrong. I'd be happy with either "constructor"
or "display", myself.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Glenn Linderman]

On 12/3/2015 5:56 PM, Chris Angelico wrote:

You come across something syntactic that begins by opening a square
bracket, and you know that its semantics are: "construct a new list".
That's what's common here.

What goes*inside*  those brackets can be one of two things:

1) A (possibly empty) comma-separated sequence of expressions

2) One or more nested 'for' loops, possibly guarded by 'if's, and a
single expression

So we have two subforms of the same basic syntax. The first one
corresponds better to the output format, in the same way that a string
literal might correspond to its repr under specific circumstances.
Neither is a literal. Neither is a call to a constructor function
(contrast "list()" or "list.__new__(list)", which do call a
constructor). So what is this shared syntax? Whatever word is used,
it's going to be a bit wrong. I'd be happy with either "constructor"
or "display", myself.


Construction.  It includes an implicit constructor call and does more.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[MRAB]

On 2015-12-04 01:56, Chris Angelico wrote:

On Fri, Dec 4, 2015 at 12:25 PM, Steven D'Aprano  wrote:

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?


You come across something syntactic that begins by opening a square
bracket, and you know that its semantics are: "construct a new list".
That's what's common here.

What goes *inside* those brackets can be one of two things:

1) A (possibly empty) comma-separated sequence of expressions

2) One or more nested 'for' loops, possibly guarded by 'if's, and a
single expression

So we have two subforms of the same basic syntax. The first one
corresponds better to the output format, in the same way that a string
literal might correspond to its repr under specific circumstances.
Neither is a literal. Neither is a call to a constructor function
(contrast "list()" or "list.__new__(list)", which do call a
constructor). So what is this shared syntax? Whatever word is used,
it's going to be a bit wrong. I'd be happy with either "constructor"
or "display", myself.


The problem with "constructor" is that it's already used for the "__new__"
class method.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [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  wrote:
>
>>> On 2015-12-03 15:09, Random832 wrote:
>>> On 2015-12-03, Laura Creighton  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

 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

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

[Andrew Barnert via Python-Dev]

On Dec 3, 2015, at 17: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  wrote:
>>> 
> On 2015-12-03 15:09, Random832 wrote:
> On 2015-12-03, Laura Creighton  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