[Python-Dev] The type of the result of the copy() method (original) (raw)

Guido van Rossum guido at python.org
Sun Oct 29 14:44:17 EDT 2017

On Sun, Oct 29, 2017 at 10:41 AM, Raymond Hettinger < raymond.hettinger at gmail.com> wrote:

> On Oct 29, 2017, at 10:04 AM, Guido van Rossum <guido at python.org> wrote: > > Without an answer to these questions I think it's better to admit defeat and return a dict instance I think it is better to admit success and recognize that these APIs have fared well in the wild.

Oh, I agree!

Focusing just on OrderedDict() and dict(), I don't see how to change the

copy() method for either of them without breaking existing code. OrderedDict is a dict subclass but really does need to have copy() return an OrderedDict.

And I wasn't proposing that. I like what OrderedDict does -- I was just suggesting that the default dict.copy() needn't worry about this.

The default behavior for any pure python class is for copy.copy() to return an instance of that class. We really don't want ChainMap() to return a dict instance -- that would defeat the whole purpose of having a ChainMap in the first place.

Of course.

And unlike the original builtin classes, most of the collection classes

were specifically designed to be easily subclassable (not making the subclasser do work unnecessarily). These aren't accidental behaviors:

class ChainMap(MutableMapping): def copy(self): 'New ChainMap or subclass with a new copy of maps[0] and refs to maps[1:]' return self.class(self.maps[0].copy(), *self.maps[1:]) Do you really want that changed to: return ChainMap(self.maps[0].copy(), *self.maps[1:]) Or to: return dict(self)

I think you've misread what I meant. (The defeat I referred to was accepting the status quo, no matter how inconsistent it seems, not a withdrawal to some other seemingly inconsistent but different rule.)

Do you really want Serhiy to sweep through the code and change all of these long standing APIs, overriding the decisions of the people who designed those classes, and breaking all user code that reasonably relied on those useful and intentional behaviors?

No, and I never said that. Calm down.

Raymond

P.S. Possibly related: We've gone out of way in many classes to have a repr that uses the name of the subclass. Presumably, this is to make life easier for subclassers (one less method they have to override), but it does make an assumption about what the subclass signature looks like. IIRC, our position on that has been that a subclasser who changes the signature would then need to override the repr. ISTM that similar reasoning would apply to copy.

I don't think the same reasoning applies. When the string returned doesn't indicate the true class of the object, debugging becomes a lot harder. If the signature in the repr() output is wrong, the user can probably deal with that. And yes, the subclasser who wants the best possible repr() needs to override it, but the use cases don't match.

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171029/6e95e171/attachment.html>

More information about the Python-Dev mailing list