[Python-Dev] Python Language Reference has no mention of list comÃprehensions
R. David Murray
rdmurray at bitdance.com
Fri Dec 4 09:52:55 EST 2015
More information about the Python-Dev mailing list
Fri Dec 4 09:52:55 EST 2015
- Previous message (by thread): [Python-Dev] Python Language Reference has no mention of list comÃprehensions
- Next message (by thread): [Python-Dev] Python Language Reference has no mention of list comÃprehensions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, 04 Dec 2015 18:38:03 +1000, Nick Coghlan <ncoghlan at gmail.com> 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 "<stdin>", line 1, in <module> 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
- Previous message (by thread): [Python-Dev] Python Language Reference has no mention of list comÃprehensions
- Next message (by thread): [Python-Dev] Python Language Reference has no mention of list comÃprehensions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list