<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 12, 2015 at 8:58 PM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/12/2015 08:01 PM, Guido van Rossum wrote:<br>
<span class="">> On Thu, Feb 12, 2015 at 7:41 PM, Ethan Furman wrote:<br>
>><br>
>> 2) always use the type of self when creating new instances<br>
>><br>
</span><span class="">>>        cons:<br>
>>          - if constructor signatures change, must override all methods which<br>
>>            create new objects<br>
><br>
</span><span class="">> Con for #2 is a showstopper. Forget about it.<br>
<br>
</span>Happy to, but can you explain why requiring the programmer to override the necessary methods, or get tracebacks, is a<br>
showstopper?  Is there a previous email thread I can read that discusses it?<br></blockquote></div><br></div><div class="gmail_extra">IIUC you're proposing that the base class should *try* to construct an instance of the subclass by calling the type with an argument, and fail if it doesn't work. But that makes the whole thing brittle in the light of changes to the subclass constructor. Also, what should the argument be? The only answer I can think of is an instance of the base class. Finally, this would require more special-casing in every built-in class (at least every built-in class that sometimes returns instances of itself).<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>