This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: dict.__init__ doesn't call subclass's __setitem__.
Type: Stage:
Components: None Versions:
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gvanrossum, jemfinch, mwh, rhettinger
Priority: normal Keywords:

Created on 2003-10-16 14:27 by jemfinch, last changed 2022-04-10 16:11 by admin. This issue is now closed.

Messages (5)
msg18663 - (view) Author: Jeremy Fincher (jemfinch) Date: 2003-10-16 14:27
The easiest way to describe this is with the code I was
using that uncovered this bug:

class TwoWayDictionary(dict):
    __slots__ = ()
    def __setitem__(self, key, value):
        dict.__setitem__(self, key, value)
        dict.__setitem__(self, value, key)

I suspected this bug might happen, so I wrote this test:

class TwoWayDictionaryTestCase(unittest.TestCase):
    def testInit(self):
        d = TwoWayDictionary(foo='bar')
        self.failUnless('foo' in d)
        self.failUnless('bar' in d)

Basically, dict.__init__ is calling dict.__setitem__
even in subclasses.
msg18664 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-10-16 14:33
Logged In: YES 
user_id=6656

.update() won't call TwoWayDictionary.__setitem__ either. 
Ditto .setdefault.

You'll see similar behaviour for lists too.

AFAIK, nowhere do the Python docs promise that the
dictionary implementation is defined in terms of certain
"primitive methods".  You may think this a bug, but it's a
whole lotta work to "fix" it.

FWIW, you might be happier using UserDict.DictMixin.
msg18665 - (view) Author: Jeremy Fincher (jemfinch) Date: 2003-10-16 14:41
Logged In: YES 
user_id=99508

If someone went to the trouble to be able to define what
"kermel methods" are used in the dict/list/whatever else
implementations, would it even be accepted, or would it be
considered too useless/slow/etc. to be bothered with?
msg18666 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-10-16 14:50
Logged In: YES 
user_id=6656

I honestly don't know.  I slightly doubt it.

It would probably be PEP material.

I wonder what Guido thinks...
msg18667 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-10-28 07:45
Logged In: YES 
user_id=80475

This isn't a bug.  Guido and I specifically discussed this
for lists and arrived at the conclusion that the methods are
to remain independent.  If someone needs __init__ to change,
they should override it also.

In general, most objects do not have a promised set of
kernel methods that propagate their effects to other
methods.  Internally, python is laced with code that
accesses objects directly and cannot be reasonably
converted.  This independence of methods is both a feature
and fact of life in the OOP world.  This is especially true
for objects where there is no universal agreement as to what
the primitives are (quick, which is more basic, dict.has_key
or dict.__contains__; should overriding one affect the
other; should overriding dict.__getitem__ affect
dict.has_key since that latter can be defined in terms of
the former).  As so it goes . . . 

History
Date User Action Args
2022-04-10 16:11:45adminsetgithub: 39418
2003-10-16 14:27:35jemfinchcreate