<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 29, 2017 at 10:41 AM, Raymond Hettinger <span dir="ltr"><<a href="mailto:raymond.hettinger@gmail.com" target="_blank">raymond.hettinger@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=""><br>
> On Oct 29, 2017, at 10:04 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
><br>
> Without an answer to these questions I think it's better to admit defeat and return a dict instance<br>
<br>
</span>I think it is better to admit success and recognize that these APIs have fared well in the wild.<br></blockquote><div><br></div><div>Oh, I agree!</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>Of course.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
class ChainMap(MutableMapping):<br>
<br>
def copy(self):<br>
'New ChainMap or subclass with a new copy of maps[0] and refs to maps[1:]'<br>
return self.__class__(self.maps[0].<wbr>copy(), *self.maps[1:])<br>
<br>
Do you really want that changed to:<br>
<br>
return ChainMap(self.maps[0].copy(), *self.maps[1:])<br>
<br>
Or to:<br>
<br>
return dict(self)<br></blockquote><div><br></div><div>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.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>No, and I never said that. Calm down. <span class="HOEnZb"><font color="#888888"></font></span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Raymond<br>
</font></span><br>
<br>
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.<br>
</blockquote></div><br></div><div class="gmail_extra">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.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>