<div dir="ltr">Good point, I withdraw my suggestion.  I think it's unfortunate for Python to have traps like this, but I don't see a nice way to protect users while still letting people do whatever they want.<br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 21, 2016 at 3:03 AM Neil Girdhar <<a href="mailto:mistersheik@gmail.com" target="_blank">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">I guess that's fair.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 21, 2016 at 2:36 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@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 class="gmail_extra"><div class="gmail_quote">On 21 April 2016 at 12:51, Neil Girdhar <span dir="ltr"><<a href="mailto:mistersheik@gmail.com" target="_blank">mistersheik@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Sometimes users inherit from builtin types only to find that their overridden methods are not called.  Instead of this being a trap for unsuspecting users, I suggest overriding the __new__ method of these types so that it will raise with an informative exception explaining that, e.g., instead of inheriting from dict, you should inherit from UserDict.<div><br></div><div>I suggest this modification to any Python implementation that has special versions of classes that cannot easily be extended, such as CPython.  If another Python implementation allows dict (e.g.) to be extended easily, then it doesn't have to raise.<br></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra">Builtins can be extended, you just have to override all the methods where you want to change the return type:<br><br>>>> from collections import defaultdict, Counter, OrderedDict<br>>>> issubclass(defaultdict, dict)<br>True<br>>>> issubclass(Counter, dict)<br>True<br>>>> issubclass(OrderedDict, dict)<br>True<br><br clear="all"></div><div class="gmail_extra">This isn't hard as such, it's just tedious, so it's often simpler to use the more subclass friendly variants that dynamically look up the type to return and hence let you get away with overriding a smaller subset of the methods.<br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br><br></div></div><div dir="ltr"><div class="gmail_extra">-- <br><div>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div></blockquote></div></blockquote></div></div>