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". Its not. The most general case is that a
tuple display is an expression which, after evaluation, constructs a tuple.
Those few cases where the compiler can optimize it into a constant are the
nits, not the majority of cases when it can't.
In fact, it's easy to find cases even now where the compiler is
insufficiently smart to recognise all the possible optimizations available.
There's no tuple simpler than the empty tuple, but Python 3.3 at least
fails to optimize that case:
py> dis(compile("()", '', 'eval'))
1 0 BUILD_TUPLE 0
3 RETURN_VALUE
The bottom line is, *in general*, the terms "tuple literal", "list
literal", "dict literal" etc. are inappropriate and incorrect, which is why
the docs correctly distinguish them from actual literals by calling
them "displays".
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
