Issue824854
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.
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) | 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) | 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) * | 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:45 | admin | set | github: 39418 |
2003-10-16 14:27:35 | jemfinch | create |