As the __int__() method is required, I believe it can return self(1) instead.

Also, probably +self normalization could be avoided in the Integral.numerator().

> self(1) instead

or, rather, type(self)(1)

Raymond and Serhiy, you were the last two active devs to touch numbers.py.

How would it work for bool or IntEnum?

> How would it work for bool or IntEnum?

Neither subclass the Integral abc.

The constraint (for which I care about) is: numerator/denominator should have same types.  The default implementation, which I propose: it's the same type as the given Integral implementation.

There is no such constrain. And no default implementation in this module depends on the constructor. It is important, the constructor is not the part of interfaces.

If you want to return the same type in denominator, just override it in your class.

> There is no such constrain.

Why not?  Any example where it does make sense to have different types for numerator and denominator?

There is no "why". There is a fact that there is no such constrain. Adding a new constrain may break existing code. If you want to add a constrain, add it in you code.

If you are interesting "why", try to search old archives for the history of creating that module. Maybe you will find something. Maybe you will need to dip deeper, in discussions about abstract classes and protocols.

> There is no "why".

Why not?  Apparently, this is a documentation error, at least.  (And I doubt there are tests for default methods.)

> If you are interesting "why", try to search old archives for the history of creating that module.

Thanks.  Sorry, I'll try harder.  So far I've found nothing to explain me why the Integral.denominator must be an 'int'.

The module documentation should not contain all historical reasons of every design decision. If you are interesting why something was done in one way or another, do your research.

One of reasons is that type(self) not always have a constructor with compatible interface. So it may work for your integer-like type, but in general case.

> The module documentation should not contain all historical reasons of every design decision.

Sure.  But, for example, there should be an explanation of why foo+foo.denominator could produce an error for a valid implementation of the Integral abc.  Such interoperability is not assumed by the docs, according to provided examples (https://docs.python.org/3/library/numbers.html#implementing-the-arithmetic-operations).

> One of reasons is that type(self) not always have a constructor with compatible interface.

I hardly can imagine a constructor for the Integral type, which doesn't accept a python integer as an argument.

Integral.__add__ is an abstract method, so it is a problem of your implementation.

> Integral.__add__ is an abstract method, so it is a problem of your implementation.

But such an implementation does satisfy all assumptions of the Integral abc, correct?

It does not satisfy your assumptions in msg416056. So you have either correct your assumptions, or change the implementation of __add__, or change the implementation of denominator in your code.

> It does not satisfy your assumptions in msg416056.

Yes, but does it fits to assumptions of the numbers module?  To be fair, there is even no requirement, that numerator/denominator are Integral instances (#25619 address also this).

BTW, it seems, the numpy integer types break my guess that numerator and denominator must have same types (I doubt that anyone uses numbers.Integral defaults, there are no tests for them in the CPython itself):
>>> a = numpy.int8(2); a
2
>>> type(a)
<class 'numpy.int8'>
>>> type(a.numerator)
<class 'numpy.int8'>
>>> type(a.denominator)
<class 'int'>
>>> type(a + a.denominator)
<class 'numpy.int64'>
>>> type(a.denominator + a)
<class 'numpy.int64'>
>>> type(a + a)
<class 'numpy.int8'>

If this is an expected behaviour for Integral types - feel free to close the bugreport.  Looks odd for me, however.