It usually isn't an effective use to time to go straight to a PR before a proposal has been discussed and accepted.

I figured it would help with decision-making. The person who started the thread asked for an implementation, and I had the free time to make one. I'm not very familiar with how the PEP process usually works, but I saw in PEP 1:

Standards Track PEPs consist of two parts, a design document and a reference implementation. It is generally recommended that at least a prototype implementation be co-developed with the PEP, as ideas that sound good in principle sometimes turn out to be impractical when subjected to the test of implementation.

Sorry if this is a distraction. It's not my intention to disrupt the normal process!

It looks like this may yet have a chance :-)

Since it is a principal point of the PEP, I suggest you to create two or more separate PRs: one does not depend on subclasses, and the other calls copy() and update().

Yet one argument against calling copy() and update() is that it would be the only case when operator depends on non-dunder methods.

@serhiy-storchaka Yes, and in the earlier stages of the proposal I felt as you did:

https://mail.python.org/archives/list/python-ideas@python.org/message/HBWBRRGXUGPT2NQLVNM3XLBHZSHKWBGI/

But Steven was strongly for this, and over time his arguments were enough to shift my view.

https://mail.python.org/archives/list/python-ideas@python.org/message/SIPJZPEUTIMZ7ETCCDUKWDIFNRN7YHMH/

Also:

Possibly relevant: I've always been frustrated and annoyed at classes
that hardcode their own type into methods... This gets really annoying really quickly. Try subclassing int, for example, where you have to override something like 30+ methods and do nothing but wrap calls to super.

It's more common to subclass dict than either list or set, so I see this as more important issue than just blindly following what seems like a less-than-ideal precedent without a really good reason to.

dict doesn't have any operators yet, so we're not bound by any prior design constraints in this area (rather, we're setting them). My example above with defaultdict shows that this has immediate benefits for both usability and maintenance.

@gvanrossum, is this enough of an issue that you would consider rejecting the proposal over it? I know that Steven and I have somewhat strongly formed opinions on this from all of the endless mailing-list threads, so it might be a good idea to continue this discussion on the python-dev thread where he can participate, if so.

Also, @serhiy-storchaka it would be pretty easy to just strip the last 5 commits at this point. I can make another PR if the two designs deviate more substantially.

@brandtbucher This won't be an issue unless you make it one. The proposal is a good one regardless of what it does with subclasses. Does the PEP explicitly address this (either in the spec or in the text about rejected alternatives or elsewhere)? If so can you point me to the text?

A general problem with honoring subclasses is that it's worse when it's done inconsistently than not at all. For immutable objects (e.g. Steven's int subclassing example) the problem is that you won't know the arguments to the subclass constructor, and you can't mutate int objects after they've been created. So you just have to suck it up. For dict, in this case copy()+update() will work. But that's just luck. C code that inserts a new key into a dict shouldn't have to look for an overridden __setitem__, it should be able to just use PyDict_SetItem.

I don't believe this was ever explicitly outlined in the PEP (probably because we didn't get much pushback relative to other decisions 😉), but the Reference Implementation section is clear - it uses bound self methods rather than unbound dict methods. We also mention the desire of subclass-preserving behavior in the Motivation section, although that is less relevant because the operators could still be manually overridden.

Thinking out loud, if dict were to grow more operators, they would likely be &, ^, and - (with the associated in-place versions, which is important). Continuing our subclass-friendliness started here would probably require, at the very least, also respecting __delitem__ and __setitem__ as well...

How do we feel about keeping the copy call and dropping the update one? I know Steven was open to that. New subclasses just have to implement copy to get fast, working versions of everything, and we get to keep a working defaultdict, etc...

I still think it's a doubtful choice (and the PEP is clear that the code there is not exactly equivalent). Can you bring this up in the python-dev thread? So far you've convinced 0 out of 2 core devs -- but you still could get the Steering Council behind you.

Can you bring this up in the python-dev thread?

Done.

Yes, I commented in the new PEP thread:

https://mail.python.org/archives/list/python-dev@python.org/message/Z5SSGCH736UWHKFGJEZROH6VKPKXIT7W/

I am going to go ahead and remove the update calls, since we've come to an agreement on that. Jury's still out on copy.

Thanks for all of the feedback @gvanrossum and @serhiy-storchaka (especially for your insightful comments on the subclass issue).

Guido just informed us that the Steering Council accepted his recommendation!

@gvanrossum: Please replace # with GH- in the commit message next time. Thanks!