What is a function parameter =[] for?

[Steven D'Aprano]

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