<p dir="ltr"><br>
On 14 Feb 2015 07:39, "Isaac Schwabacher" <<a href="mailto:ischwabacher@wisc.edu">ischwabacher@wisc.edu</a>> wrote:<br>
><br>
> On 15-02-13, Guido van Rossum wrote:<br>
> > Are you willing to wait 10 days for an answer? I'm out of round tuits for a while.<br>
><br>
> IIUC, the argument is that the Liskov Substitution Principle is a statement about how objects of a subtype behave relative to objects of a supertype, and it doesn't apply to constructors because they aren't behaviors of existing objects. So other overriding methods *should* be able to handle the same inputs that the respective overridden methods do, but constructors don't need to. Even though __init__ is written as an instance method, it seems like it's "morally" a part of the class method __new__ that's only split off for convenience.</p>
<p dir="ltr">A potentially helpful example is to consider a type system where Square is a subclass of Rectangle.</p>
<p dir="ltr">To specify a Rectangle takes a height and a width, but a Square only needs the length of one side, and letting the height and width be specified independently would be outright wrong.</p>
<p dir="ltr">Many possible operations on a Square also *should* formally return a Rectangle, as doing something like doubling the height gives you a result that isn't a square any more. (That's also why shapes must be immutable for this particular type hierarchy to make any sense)</p>
<p dir="ltr">(You can construct similar examples for Circle & Ellipse, and Python's numeric hierarchy is a real-world example of some of the complexity that can arise)</p>
<p dir="ltr">There's simply no sensible default behaviour other than the status quo in the face of scenarios like that - whether or not there's a better answer than "return an instance of the parent class" for any given inherited method depends entirely on the invariants of the subclass and how they differ from those of the parent class.</p>
<p dir="ltr">It's certainly possible to write methods that return a new instance of the current type (that's common in alternative constructors, for example), but it usually involves placing additional expectations on the developers of subclasses. That's most commonly seen within the confines of a single project, or when defining a development framework, rather than in libraries that choose to expose some public types and also supports their use as base types.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> If this message is unclear, it's because I don't really understand this myself and I'm trying to articulate my best understanding of what's been said on this thread and those it links to.<br>
><br>
> ijs<br>
><br>
> > On Fri, Feb 13, 2015 at 10:22 AM, Alexander Belopolsky <<a href="mailto:alexander.belopolsky@gmail.com">alexander.belopolsky@gmail.com</a>(javascript:main.compose()> wrote:<br>
> ><br>
> > ><br>
> > > On Fri, Feb 13, 2015 at 1:19 PM, Alexander Belopolsky <<a href="mailto:alexander.belopolsky@gmail.com">alexander.belopolsky@gmail.com</a>(javascript:main.compose()> wrote:<br>
> > > >><br>
> > > >> FWIW you're wrong when you claim that "a constructor is no different from any other method". Someone else should probably explain this (it's an old argument that's been thoroughly settled).<br>
> > > ><br>
> > > ><br>
> > > > Well, the best answer I've got in the past [1] was "ask on python-dev since Guido called the operator overriding expectation." :-)<br>
> > ><br>
> > ><br>
> > > And let me repost this bit of history [1]:<br>
> > ><br>
> > > Here is the annotated pre-r82065 code:<br>
> > ><br>
> > > 39876 gvanrossum def __add__(self, other):<br>
> > > 39876 gvanrossum if isinstance(other, timedelta):<br>
> > > 39928 gvanrossum return self.__class__(self.__days + other.__days,<br>
> > > 39876 gvanrossum self.__seconds + other.__seconds,<br>
> > > 39876 gvanrossum self.__microseconds + other.__microseconds)<br>
> > > 40207 tim_one return NotImplemented<br>
> > > 39876 gvanrossum<br>
> > ><br>
> > ><br>
> > ><br>
> > > [1] <a href="http://bugs.python.org/issue2267#msg125979">http://bugs.python.org/issue2267#msg125979</a><br>
> > ><br>
> > ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > --Guido van Rossum (<a href="http://python.org/~guido(http://python.org/~guido)">python.org/~guido(http://python.org/~guido)</a>)<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>