[issue1367711] Remove usage of UserDict from os.py

Martin v. Löwis added the comment: I'm rejecting this patch, for the same reasons as issue2144. If further discussion is needed, please discuss on python-dev. -- resolution: -> rejected status: open -> closed _ Tracker <[EMAIL PROTECTED]>

[issue1367711] Remove usage of UserDict from os.py

Raymond Hettinger added the comment: I think some variant of these patches was rejected before and part of these reason had to do with subtle semantic changes when switching from an old-style class (inheriting from UserDict) to a new-style class (inheriting from dict). There were also some co

[issue1367711] Remove usage of UserDict from os.py

Alexander Belopolsky added the comment: See comments at issue2144. Benjamin Peterson demonstrated a more than 2x speedup on a micro-benchmark. Plus, the fact that two people were motivated enough to independently produce a near-complete patch is worth something.

[issue1367711] Remove usage of UserDict from os.py

Raymond Hettinger added the comment: Recommend closing this one. There is no point in going on the warpath against UserDict. There are downsides to changing it and almost no advantage (saving an import, that's it). The primary motivation for this bug report is the OP's distaste for UserDict

[issue1367711] Remove usage of UserDict from os.py

Martin v. Löwis added the comment: It's intentional that dict doesn't dynamically bind any calls; to properly replace the semantics of dict, you have to implement *all* API. There might be lack of documentation of this aspect, however, that is a separate issue from the one being discussed here.

[issue1367711] Remove usage of UserDict from os.py

Alexander Belopolsky added the comment: I would say dict's failure to call overloaded __setitem__ from setdefault is a dict implementation problem which should be either fixed, or clearly documented as warning to anyone who wants to derive from dict. A fix would be trivial: =

[issue1367711] Remove usage of UserDict from os.py

Andrew Dalke added the comment: Ahh, so the bug here that the environ dict should use neither UserDict nor dict, it should implement the core {get,set,del}item and keys and use DictMixin. Martin mentioned that the patch doesn't support setdefault. He didn't note though that the current code

[issue1367711] Remove usage of UserDict from os.py

Raymond Hettinger added the comment: > it's better to derived from dict for things like > this than to derive from UserDict or UserDictMixin That's true for UserDict but not DictMixin. IIRC, the latter will continue to exist in Py3.0 and it has a purpose that is much different than UserDict or

[issue1367711] Remove usage of UserDict from os.py

Andrew Dalke added the comment: I should have added my preference. I would like to see UserDict replaced with dict. I didn't like seeing the extra import when I was doing my performance testing, through truthfully it's not a bit overhead. As for future-proofing, of course when there's a chan

[issue1367711] Remove usage of UserDict from os.py

Andrew Dalke added the comment: I was optimization tuning and wondered why UserDict was imported by os. Replacing UserDict with dict passes all existing regression tests. I see the concerns that doing that replacement is not future proof. Strange then that Cookie.py is acceptable. There a

[issue1367711] Remove usage of UserDict from os.py

Raymond Hettinger added the comment: I don't think the point of this patch is worth doing. The existing code is not buggy and runs fine. Subclassing from dict increases the likelihood that an error will be introduced either now or in the future as the dict object evolves. Recommend this be

[issue1367711] Remove usage of UserDict from os.py

Changes by Christian Heimes: -- assignee: tiran -> keywords: +easy _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list

[issue1367711] Remove usage of UserDict from os.py

Changes by Christian Heimes: -- assignee: -> tiran nosy: +tiran type: -> rfe versions: +Python 2.6 -Python 2.5 _ Tracker <[EMAIL PROTECTED]> _