Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Antoon Pardon <antoon.pardon@rece.vub.ac.be>
Newsgroups: comp.lang.python
Subject: Re: What is a function parameter =[] for?
Date: Wed, 25 Nov 2015 19:27:56 +0100
Lines: 40
Message-ID: <mailman.84.1448476089.20593.python-list@python.org>
References: <d9045bdd-a5d4-4c5c-9fd3-3d54f6b50862@googlegroups.com> <56547337.4000709@rece.vub.ac.be> <CAPTjJmoGt3B_zTVd8dVLHNeanX=4g1yhN-PLpXzZoYiKb9HYuw@mail.gmail.com> <56547C53.8030407@rece.vub.ac.be> <CAPTjJmqAMwnxBZ97umsNg255v47dsQD6qEr0ysECtGiZ409k0Q@mail.gmail.com> <5654864E.2070906@rece.vub.ac.be> <CAPTjJmoUtwHzOEwcObh5hzUDbz-713kVE_Kq-rg_bmYFHE_tYw@mail.gmail.com> <56549324.8020607@rece.vub.ac.be> <CALwzidmAKgmxjR=nDU4bPn5iy9AqCCiT=nTQYSORADCtpdM+SA@mail.gmail.com> <56549F15.40206@rece.vub.ac.be> <CALwzidkuiSfyXxiQ8H6YSEtEL5cqj6sOUPXdUru6n8XtGnvzug@mail.gmail.com> <5654B037.6020107@rece.vub.ac.be> <CALwzidkRj7G-W3UdtdczM10kHmHZ_qrdOoPNcJNjiw2QcNr0YQ@mail.gmail.com> <mailman.33.1448398558.20593.python-list@python.org> <n32jqq$k4j$1@dont-email.me> <mailman.35.1448400323.20593.python-list@python.org> <56550273$0$1585$c3e8da3$5496439d@news.astraweb.com> <mailman.64.1448445391.20593.python-list@python.org> <5655f27b$0$1614$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0
In-Reply-To: <5655f27b$0$1614$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:99472

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. Then I have expaned that to that something
like (3, 5, 8) is a literal. I never argued that tuple expressions
in general are literals. 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.

> 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.

The nits, depend on what someone tries to argue. Since I didn't try
to argue that tuple displays in general are literals but argued
for very specific tuple values to be literals, you starting
about tuple displays is going of on a tangent that has little
to do with what I was arguing.

-- 
Antoon