On Thu, 26 Nov 2015 05:27 am, Antoon Pardon wrote: > Op 25-11-15 om 18:40 schreef Steven D'Aprano: >> On Wed, 25 Nov 2015 08:56 pm, Antoon Pardon wrote: >> >>> Since (x, y, z) is not a fixed value, it is not a literal. >> >> Right. And therefore, (x, y, z) syntax is not syntax for a literal. Hence >> why the Python docs call it a tuple display instead of a tuple literal -- >> no matter what x, y, z are. Even if they themselves are literals, that's >> just a special case that *some* compiler versions may be able to handle. >> >> You call this "picking nits", but if so, they are nits that are twice the >> size of an an elephant and painted bright yellow. Your language arguing >> about "tuple literals" seems to be based on the idea that it is usually a >> constant and that cases like (x+1, y+2) is some unusual, rare corner >> case -- what you call "nits". > > I don't know what you are talking about. The first thing I have argued > is that () is a literal.
How embarrassing that Python doesn't treat it as a literal, but as an expression. > And one way I supported my point was with the > following quote from the python language reference. > > Literals are notations for constant values of some built-in types. > > And I think that the things I argued were literals, were in fact > constant values of some built-in type. Since you didn't bother to provide a link, I googled for that quote, and here's a page that gives the canonical set of literals available in Python: https://docs.python.org/2/reference/lexical_analysis.html#literals https://docs.python.org/3/reference/lexical_analysis.html#literals I see strings, ints, floats, but no tuples, lists or dicts. It takes either great chutzpah or great stupidity to use the official documentation to argue in favour of a point which is contradicted by that very same documentation. The Python docs *define* "literal" to only refer to certain types. That definition is related to the grammar of Python: https://docs.python.org/3/reference/grammar.html It would be silly, wasteful and error-prone to define two sorts of tuple displays: "tuple displays where each component is a literal" "tuple displays where at least one component is not a literal" as you want to distinguish. Now obviously this is a legitimate distinction to make in some circumstances: the compiler may (or may not) be able optimise the first case in some way. But it's not a distinction that makes sense for the parser. It makes no difference to the parser whether you have (1, 2) or (1, x), it gets parsed the same way. To the parser, there is only one sort of tuple display, and it is absolutely not a literal. The terminology used for lexical analysis is the terminology used for the parser, not the peephole optimizer. All Python compilers must have a parser, and they must agree on the grammar. But optimization is implementation dependent. There is talk about adding a switch to Python to disable all peep-hole optimizations, which means whether (1, 2) gets compiled to a BUILD_CONST or a BUILD_TUPLE will depend on a runtime switch. The bottom-line is that tuples, lists, sets and dicts are compound data types, and while it is easy and convenient to talk about "tuple literals" that's sloppy language which is not supported by the language reference. When this fact is pointed out, there are multiple sensible strategies available: (1) we can acknowledge that "tuple literal" is sloppy language, and vow never to use it again; (2) we can acknowledge that "tuple literal" is sloppy language, but argue that it's convenient to use, more familiar than "tuple display", and most people will understand what you mean, and so we'll continue to use it no matter how sloppy it is; (3) or we can declare that the definition in the language reference is wrong, that we know better. What I've never seen before though is what you appear to have done: (4) Respond that the language reference, which clearly and obviously does NOT include tuples in the list of types that can be described as "literals", supports your claim that tuples are literals. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
