Tuple/List identity guarantees Was(Re: __iadd__ and fellows missing (Python 2.2))

[Mike C. Fletcher]

This little mental exercise all started when Tim pointed out the tuples 
_won't_ work for the pattern (well, he pointed out that there's no 
guarantee that imutable values (particularly empty tuples) will always 
be seperate objects).  So using an empty tuple for the pattern is no 
longer suitable.

To the best of my knowledge, there _is_ an implicit guarantee (at least, 
such a guarantee is assumed in a lot of code) that two different 
_mutable_ objects (such as lists or instances) will _always_ return 
different id values, and thus always compare unequal with "is".  Sure, 
there are optimisation tricks (copy-on-write) that could invalidate such 
a guarantee, but somewhere under the covers the implementation needs to 
be tracking the "real id" of the list to implement those semantics, so 
the implementation can still return that id should someone ever 
introduce those optimisations.

Note: the "second case" in your list is something that's explicitly 
out-of-scope for this pattern, not impossible, but not something I'm 
interested in making easier.  If you want to specify, do so, if not, 
just leave the argument out.

Oh, I care deeply for the Timbot's feelings.  Six years of fighting a 
bloody guerilla war against him ;) has made me come to love the little 
floating ball of light :) (though the strange looking guy that always 
hangs out around him kinda freaks me out ;) ).

Incidentally, trying to figure out how long we've been trading volleys, 
I found an article from just about a year ago:

http://groups.google.com/groups?selm=mailman.987583046.24994.python-list%40python.org
	
At the time I was so burried in work I guess I didn't file that lack of 
guarantee away in active storage.  Though, checking my code to change 
all the NULL = () to NULL = [], I only found a single case (written 
_before_ that message) where I had used NULL = () rather than NULL = [], 
so I suppose at the code-writing level it must have lodged somewhere. 
Hmm, there's hope you might change me yet, Tim :) .

Reminds me, where have all the optimisation challenges gone these days? 
  Tim, Christian and I used to spend whole minutes on those babies, and 
now all we can do is bat around recycled debates on object identity :) .

Have fun,
Mike


Steve Holden wrote:
> "Mike C. Fletcher" <mcfletch at rogers.com> wrote ...
...
>>NULL = []
>>
> 
> Note that this does indeed cause the NULL variable to refer to a specific
> instance of the empty list (and a tuple would be acceptable here rather than
> a list).
> 
...
> The only situation this will not help you with is if you need to distinguish
> between the following calls:
> 
>     BasicProperty("One")
> 
>     BasicProperty("One", defaultValue=NULL)
> and
>     BasicProperty("One", defaultValue=())
...
> The third case is trickier, however, as there is no guarantee that the
> implementation won't optimize, so it is permissible for different
> implementations to use either the same or different lists (or tuples).
...
> As for the "designed purpose of default arguments" :) .  I see the value
>> "no value/not specified" as a perfectly suitable default value.  Sure,
>> it may offend your sensibilities, but when has that stopped me in the
>> past ;) .
>>
> 
> Apparently never, if the above is typical of your disregard for the bot's
> feelings.
> 
> regards
>  Steve
...