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

[Guido van Rossum]

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>