RetroSearch Browse

Sun Jul 11 07:09:59 CEST 2004 · http://mail.python.org/pipermail/python-dev/2004-July/046041.html

[Michael Chermside]
> ...
> My question is this: is this behavior intentional, or is it an "implementation
> detail"? If intentional, is there a reason for the choice, or is it just that
> one or the other behavior needed to be chosen?
>
> [PS: I'm hoping that a good answer to this question will allow me to close bug
> 748126]

It's undefined, but the docs could stand to explicitly point out that
it's undefined.  748126 is intimately related to the thread starting
here, BTW:

    http://mail.python.org/pipermail/python-dev/2003-June/035970.html

I don't think it's an accident that implementations are likely to keep
"the old key".  A natural way to code setitem(self, key, value) is

    if key in self:
        replace the value associated with key
    else:
        raise KeyError

While there was no deliberate attempt to do so, ZODB's BTrees (and
Buckets) also act this way:

>>> from BTrees.OOBTree import OOBTree
>>> s1 = 'a' + 'b'
>>> s2 = 'a' + 'b'
>>> id(s1)
10043520
>>> id(s2)  # s1 and s2 are == but not the same object
10044416
>>> b = OOBTree()
>>> b[s1] = 1
>>> id(b.keys()[0])
10043520
>>> b[s2] = 2   # replaces the value associated with s2 (== s1)
>>> len(b)   # still only 1 pair in this tree
1
>>> id(b.keys()[0])   # the key object didn't change
10043520
>>> b[s1]  # and the associated value did change
2
>>>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-July/046041.html below:

[Python-Dev] Equal but different keys in dicts