According to the reference manual, "None of the types defined in [numbers] module can be instantiated."  However,

>>> from numbers import *
>>> Number()
<numbers.Number object at 0x1005e5080>

This can probably be fixed by making Number.__hash__ an abstract method.

Attached patch fixes the issue and passes regression tests, so most likely the ability to instantiate Number is not an intentional feature.

"pass" should probably be replaced with a meaningful docstring, but I would like to hear from others on whether the solution is conceptually correct before making it commit-ready.

I'd say that this should be fixed, it breaks the expectancy imposed by the documentation, so +1 from me.

I left a couple of comments on Rietveld.

Hi Alexander,

Can you please address the reviews and turn this patch into a GitHub PR, please?

I'm changing the versions to Python 3.8 and 3.9 for this bug.

Usually, setting hash to None is the proper way to turn-off hashability.  And it's possible that existing code has subclassed Number and provided other methods but not __hash__, so this could potentially break their code.  On the other hand, it would be desirable to prevent instantiation, perhaps using some other mechanism would be better.  I'll take a deeper look at this when I get a chance.

I looked into this a bit more and don't see another non-invasive way of blocking instantiation.

Marking for Guido to take a look at.  He's the expert on ABCs and typing and is the originator of the __hash__ = None approach to turning off hashability.

Guido, would you like number subclasses to require an override of __hash__ or is the accidental instantiation of Number() something we even care about (I think this unlikely to ever arise in practice)?  My suggestion is to deem it harmless and leave it as is.

Let's not do this. We've survived this long.