Death to tuples!

[Mike Meyer]

Antoon Pardon <apardon at forel.vub.ac.be> writes:
> On 2005-12-02, Bengt Richter <bokr at oz.net> wrote:
>> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>>>On 2005-11-30, Duncan Booth <duncan.booth at invalid.invalid> wrote:
>>>> Antoon Pardon wrote:
>>>I think one could argue that since '[]' is normally evaluated when
>>>the expression containing it is excuted, it should also be executed
>>>when a function is called, where '[]' is contained in the expression
>>  ^^^^^^^^^^^^^^^^^^^^^^^[1] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>determining the default value.
>>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^[2]
>> Ok, but "[]" (without the quotes) is just one possible expression, so
>> presumably you have to follow your rules for all default value expressions.
>> Plain [] evaluates to a fresh new empty list whenever it is evaluated,
> Yes, one of the questions I have is why python people whould consider
> it a problem if it wasn't.

That would make [] behave differently from [compute_a_value()]. This
doesn't seem like a good idea.

> Personnaly I expect the following pieces of code
>   a = <const expression>
>   b = <same expression>
> to be equivallent with
>   a = <const expression>
>   b = a
> But that isn't the case when the const expression is a list.

It isn't the case when the const expression is a tuple, either:

x = (1, 2)
>>> (1, 2) is x
False
>>> 

or an integer:

>>> a = 1234
>>> a is 1234
False
>>> 

Every value (in the sense of a syntactic element that's a value, and
not a keyword, variable, or other construct) occuring in a program
should represent a different object. If the compiler can prove that an
value can't be changed, it's allowed to use a single instance for all
occurences of that value. Is there *any* language that behaves
differently from this?

> A person looking at:
>   a = [1 , 2]
> sees something resembling
>   a = (1 , 2)
> Yet the two are treated very differently. As far as I understand the
> first is translated into somekind of list((1,2)) statement while
> the second is build at compile time and just bound.

No, that translation doesn't happen. [1, 2] builds a list of
values. (1, 2) builds and binds a constant, which is only possible
because it, unlike [1, 2], *is* a constant. list(1, 2) calls the
function "list" on a pair of values:

>>> def f():
...  a = [1, 2]
...  b = list(1, 2)
...  c = (1, 2)
... 
>>> dis.dis(f)
  2           0 LOAD_CONST               1 (1)
              3 LOAD_CONST               2 (2)
              6 BUILD_LIST               2
              9 STORE_FAST               0 (a)

  3          12 LOAD_GLOBAL              1 (list)
             15 LOAD_CONST               1 (1)
             18 LOAD_CONST               2 (2)
             21 CALL_FUNCTION            2
             24 STORE_FAST               2 (b)

  4          27 LOAD_CONST               3 ((1, 2))
             30 STORE_FAST               1 (c)
             33 LOAD_CONST               0 (None)
             36 RETURN_VALUE        

> This seems to go against the pythonic spirit of explicit is
> better than implicit.

Even if "[arg]" were just syntactic sugar for "list(arg)", why would
that be "implicit" in some way?

> It also seems to go against the way default arguments are treated.

Only if you don't understand how default arguments are treated.

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.