gh-83448: Fix dict's __missing__ documentation

[bharel]

According to the mailing list discussion, fixed dict's documentation to account for get() not calling __missing__ and moved __missing__ from the data model to dict as it's a dict-only method and not part of the Mapping ABC.

• Issue: Fix dict's __missing__ documentation #83448

[bharel]

bump

[terryjreedy]

My first thought is that the entry should stay where it is, though something may need to be added somewhere. Special method should not have to be part of an ABC to be documented in the special methods doc. This section long predated ABCs. I will have to look at the linked discussion when I have more time. So I don't know what change, if any, to suggest at the moment.

[bharel]

Special method should not have to be part of an ABC to be documented in the special methods doc.

Thing is, I'm not implying any opinion on whether it should be there or not.
What I I'm saying, is that it should be consistent.

At the moment, you have __reduce__ in pickle's docs, __subclasshook__ in abc's docs, and other dunders at their appropriate or relevant places. You don't have all dunders in the same location, apart from those relevant to all objects and classes.

Continuing with that logic, __missing__ should probably be in dict's docs, as that's the only location where it's relevant. Otherwise the documentation is inconsistent.

Furthermore - it's specifically dict.__missing__, not object.__missing__. The docs are misleading in the current state. (Discussion @ mailing list)

As a side note, the PR changes dict.get documentation as well.

[slateny]

Per Guido on the mailing list, maybe @rhettinger can suggest something (seeing that you reviewed/merged #17910 as well).

[merwok]

Suggested change

	Not implemented by default. Called by :class:`dict`\ .\ :meth:`__getitem__`
	Not implemented by default. Called by :meth:`dict.__getitem__`

[merwok]

I agree about not moving the entry.
Other magic methods are also documented as object.__iter__ and so on. In this context it means «some object», not «the object type». Improving that would be a separate issue.