Showing content from http://mail.python.org/pipermail/python-dev/attachments/20160508/ad7d89f3/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 8, 2016 at 4:49 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8 May 2016 at 08:39, Serhiy Storchaka <<a href="mailto:storchaka@gmail.com">storchaka@gmail.com</a>> wrote:<br>
> Should alternative constructor call __new__ and __init__ methods? Thay can<br>
> change signature in derived class.<br>
<br>
</span>I think this is typically the way to go (although, depending on the<br>
specific type, the unpickling related methods may be a more<br>
appropriate way for the alternate constructor to populate the instance<br>
state)<span class=""><br></span></blockquote><div><br></div><div>Honestly, either of these sounds like fragile, even though I really want the alternative constructor to return an instance of the subclass (else why invoke it through the subclass).<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Should it complain if __new__ or __init__ were overridden?<br>
<br>
</span>If there are alternate constructors that depend on either the<br>
signature of __new__/__init__, unpickling support, or some other<br>
mechanism for creating new instances, this should be mentioned in the<br>
class documentation as a constraint on subclasses - if subclasses<br>
don't want to meet the constraint, they'll need to override the<br>
affected alternate constructors.<br></blockquote><div><br></div><div>Putting this constraint in the docs sounds fragile too. :-(<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Nick.<br>
<br>
P.S. The potential complexity of that is one of the reasons the design<br>
philosophy of "prefer composition to inheritance" has emerged -<br>
subclassing is a powerful tool, but it does mean you often end up<br>
needing to care about more interactions between the subclass and the<br>
base class than you really wanted to.<span class="HOEnZb"></span><br></blockquote></div><br></div><div class="gmail_extra">Indeed!<br><br></div><div class="gmail_extra">We could also consider this a general weakness of the "alternative constructors are class methods" pattern. If instead these alternative constructors were folded into the main constructor (e.g. via special keyword args) it would be altogether clearer what a subclass should do.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4