numbers module

[Gouvernathor]

The signature of Rational.__truediv__ is marked as the following:

First of, _ComplexLike sounds like it should be numbers.Complex. But second, the signature should be more refined :

• the divisor cannot be just any value, it has to be a number, so at a minimum numbers.Complex instead of Unknown. The typing signature should be (self, Complex) -> Complex.
• when passing a Real as a divisor, the result cannot have an imaginary part and must be Real too. I'd go as far as saying that a Rational divisor would yield a Rational dividend. In any case, a (self, Real) -> Real overload should be defined. And as a bonus, a (self, Rational) -> Rational one too.

[srittau]

Please note that your IDE's understanding of the types is a poor representation of how the types are annotated in typeshed. Rational has no annotations for __truediv__ at the moment, instead the signature is inherited from Complex:

typeshed/stdlib/numbers.pyi

Lines 91 to 92 in 4005c2f

	@abstractmethod
	def __truediv__(self, other) -> _ComplexLike: ...

other isn't annotated at all, at the moment. See also the note about _ComplexLike at the beginning of the file:

typeshed/stdlib/numbers.pyi

Lines 4 to 8 in 4005c2f

	# Use _ComplexLike, _RealLike and _IntegralLike for return types in this module
	# rather than `numbers.Complex`, `numbers.Real` and `numbers.Integral`,
	# to avoid an excessive number of `type: ignore`s in subclasses of these ABCs
	# (since type checkers don't see `complex` as a subtype of `numbers.Complex`,
	# nor `float` as a subtype of `numbers.Real`, etc.)

We of course accept any improvements in this area (and everywhere else)!

[Gouvernathor]

Well, my type checker (pyright) does consider float as a suclass of Real, so the way it works seems right to me considering the information that it's given.
In any case, I can (eventually) submit a merge request with basically what I proposed but with you local types instead of the official numbers ones, and also applied to the other operations. But I'm not a typing virtuoso so it will need a second look.

But having thought a little about it, maybe an implementation of Rational that would return a complex from the division of two rationals may fit in the python bounds of the numbers interface. Hell, it may even make some mathematical sense for all I know.
What I was talking about is the behavior of float, int, Decimal and Fractions but it may be a limitation on Rational at-large.
I'll be asking about it on the Python Discourse.