Death to tuples!

[Antoon Pardon]

On 2005-11-28, Duncan Booth <duncan.booth at invalid.invalid> wrote:
> Antoon Pardon wrote:
>
>>> >>> def func(x):
>>> ...   if x in [1,3,5,7,8]:
>>> ...      print 'x is really odd'
>>> ...
>>> >>> dis.dis(func)
>>> ...
>>>    3          20 LOAD_FAST                0 (x)
>>>               23 LOAD_CONST               2 (1)
>>>               26 LOAD_CONST               3 (3)
>>>               29 LOAD_CONST               4 (5)
>>>               32 LOAD_CONST               5 (7)
>>>               35 LOAD_CONST               6 (8)
>>>               38 BUILD_LIST               5
>>>               41 COMPARE_OP               6 (in)
>> 
>> I'm probably missing something, but what would be the problem if this
>> list was created during compile time?
>
> Not much in this particular instance. 'x in aList' is implemented as 
> aList.__contains__(x), so there isn't any easy way to get hold of the 
> list[*] and keep a reference to it. On the other hand:
>
> def func(x):
>     return x + [1, 3, 5, 7, 8]
>
> we could pass in an object x with an add operator which gets hold of its 
> right hand operand and mutates it.
>
> So the problem is that we can't just turn any list used as a constant into 
> a constant list, we need to be absolutely sure that the list is used only 
> in a few very restricted circumstances, and since there isn't actually any 
> benefit to using a list here rather than a tuple it hardly seems 
> worthwhile.

The question is, should we consider this a problem. Personnaly, I 
see this as not very different from functions with a list as a default
argument. In that case we often have a list used as a constant too.

Yet python doesn't has a problem with mutating this list so that on
the next call a 'different' list is the default. So if mutating
a list used as a constant is not a problem there, why should it
be a problem in your example?

-- 
Antoon Pardon