Can we at least make it use the constructor (if there's a custom one)? Seems like a reasonable compromise to me (let whoever implements a custom __new__ deal with argument variance).
Eg, make it use a __new__ like this: >>> class FancyInt(int): ... def __new__(self, value): ... return int.__new__(FancyInt, value) ... ... def __repr__(self): ... return "FancyInt(%s)" % super().__repr__() ... >>> x = FancyInt(1) >>> >>> x FancyInt(1) >>> x += 1 >>> x # it should be FancyInt(2) 2 Thanks, -- Ionel Cristian Mărieș, blog.ionelmc.ro On Fri, Feb 13, 2015 at 6:01 AM, Guido van Rossum <gu...@python.org> wrote: > On Thu, Feb 12, 2015 at 7:41 PM, Ethan Furman <et...@stoneleaf.us> wrote: > >> On 02/12/2015 06:39 PM, Alexander Belopolsky wrote: >> >> > In my view, a constructor is no different from any other method. If >> the designers of the subclass decided to change the >> > signature in an incompatible way, they should either override all >> methods that create new objects or live with tracebacks. >> >> > On the other hand, if all I want in my Date class is a better >> __format__ method, I am forced to override all operators >> > or have my objects silently degrade [...] >> >> So there are basically two choices: >> >> 1) always use the type of the most-base class when creating new instances >> >> pros: >> - easy >> - speedy code >> - no possible tracebacks on new object instantiation >> >> cons: >> - a subclass that needs/wants to maintain itself must override all >> methods that create new instances, even if the only change is to >> the type of object returned >> >> 2) always use the type of self when creating new instances >> >> pros: >> - subclasses automatically maintain type >> - much less code in the simple cases [1] >> >> cons: >> - if constructor signatures change, must override all methods which >> create new objects >> >> Unless there are powerful reasons against number 2 (such as performance, >> or the effort to affect the change), it sure >> seems like the nicer way to go. >> >> So back to my original question: what other concerns are there, and has >> anybody done any benchmarks? >> > > Con for #2 is a showstopper. Forget about it. > > -- > --Guido van Rossum (python.org/~guido) > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/contact%40ionelmc.ro > >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
