gh-135575: MutableMapping.update: use .items() in the Mapping case.

[randolf-scholz]

• Issue: MutableMapping.update performance improvement #135575

[eendebakpt]

Suggested change

	Improved performance of ``MutableMapping.update``.
	Improved performance of :meth:`MutableMapping.update`.

[randolf-scholz]

I actually tried this one first, but CI complained that it cannot find the RST-reference.

https://github.com/python/cpython/compare/b78241be0ce1147a9b79b50edf2b8ddb95852f37..d6f4c823eaaa30642984f3a30e02f26c00112f23

[eendebakpt]

Ah sorry about that. It probably should be something like :meth:`collections.abc.MutableMapping.update`.

[rhettinger]

I don't think this should change. This is Guido's code and he designed it to only depend on the abstract methods required by the API rather than downstream mixins. Also, this would be a change in behavior if items() has been overridden to have different behavior than you expect.

In general, the ABC mixin methods have been designed as plainly as possible to serve as a specification or guide to implementers. They are not in the optimization business.

[randolf-scholz]

There are already plenty of places where one mixin depends on other mixins:

• Mapping.__eq__(other) uses self.items() and other.items().
• MutableSequence.remove uses mixin .index.
• MutableSequence.extend uses mixin .append.
• MutableSequence.__iadd__ uses mixin .extend.
• MutableSet.clear uses mixin .pop.
• MutableSet.__ixor__ uses mixin .clear.

[rhettinger]

Nevertheless, it would be a change in behavior and it alters Guido's intentional design choices.

[gvanrossum-ms]

Thanks @rhettinger. The methods here exist to specify the semantics, not as a performant basis for subclasses.

[randolf-scholz]

@rhettinger Does the same reasoning also apply to #135312?