Python de jure vs CPython de facto?

Python Help
1

I came across this question on Stack Overflow and my first instinct was that it seems unreasonable - after all, the answer from the cited previous question clearly lays out the algorithm used to implement == in terms of the operands’ __eq__ methods by showing the actual code, and the documentation for NotImplemented itself seems to describe the behaviour.

But this got me thinking. Is it really intended that the documentation on python.org fully specifies the language? To what extent is the behaviour of the reference CPython implementation intended to be normative, where not explicitly commented upon?

2

Having lurked on python-dev for some years, I feel fairly safe in saying that there is a desire to make the language reference specify the language precisely, but without sacrificing readability. It’s a work in progress. (Compare CPython 1.4 Data Model.) A PR that improves precision or readability in some section gets considered thoughtfully.

As one who tinkers with an alternative implementation, I am always relieved when authors take time to make the distinction, if necessary, between what should be expected of Python the language and what CPython happens to do.

In the case of == and __eq__ the logic is quite clever, but specified by the language, with no freedom for the implementer AFAICT. There is some delicacy around the tempting is short-cut: the assumption that a is b implies a == b, which is not quite true.

For most people Python is just CPython and they tend to rely on the observed behaviour to define the language. This is mostly harmless.

3

Indeed; it’s definitely NOT a safe optimization. However, there is a slightly different comparison type, the “matching object in a collection” comparison, which is defined as x is y or x == y - and in that case, it’s not an optimization but part of the definition (eg to ensure that everything you get by iterating over a collection really is in that collection).

1 Like