<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Apr 21, 2016 at 1:58 AM Neil Girdhar <<a href="mailto:mistersheik@gmail.com">mistersheik@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The pros are that unsuspecting users won't fall into the trap associated with inheriting from dict, list or set. ...  It's people who don't know the problems and have no way of finding out until they spend a day debugging why overriding some method on a derived class of a derived class that ultimately inherits from dict doesn't work.</div></div></blockquote><div><br></div><div>I feel your pain. However, what you see as a failure or defect of the builtins is actually a feature! :-)</div><div><br></div><div>The downstream programmer should not be expected to know the implementation details of a dict. You don't want to read the source, you just want to use the public interface. You should be able to subclass and override methods as you like without worrying about hidden internal relationships. You should be able to override ``__getitem__`` without accidentally affecting things like ``values``.</div><div><br></div><div>I guess it's a case of "a little knowledge is dangerous". Someone who knows nothing about dict implementation would not expect to see a change in method A because of an override of method B. The expert is keeping the novice safe. It's the journeyman who suffers.</div></div></div>