What is the intended use case for the typing.SuportsXyz protocols?
I was excited to learn about SupportsInt, SupportsFloat, and SupportsComplex protocols decorated with @runtime_checkable because I thought they bridged the gap between ABCs and typing protocol classes, allowing consistent type checks by static tools and at runtime. However, I am unable to see how to use those classes in practice. For example, SupportsComplex: I understand at runtime the @runtime_checkable decorator merely checks whether __complex__ exists in the type, but that is not a good predictor of how to use a numeric value. Types that actually can be converted to complex fail the insinstance check with SupportsComplex. That's the case of built-in int and float, as well as NumPy integer and float types like float16 and uint8. On the other hand, SupportsInt suggests that I can convert a complex to int, but in fact the int and float types implement __complex__ only to provide a better error message, according to Guido van Rossum in an earlier thread here.
isinstance(1+0j, SupportsInt) True int(1+0j) Traceback (most recent call last): ... TypeError: can't convert complex to int
The issue with SupportsInt also happens with SupportsFloat. In addition, the way Mypy interprets these protocol classes is not the same as what we can see at runtime. Given the above, what are recommended use cases for the runtime checkable SupportsInt, SupportsFloat, and SupportsComplex? Cheers, Luciano -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg
FWIW Luciano has addressed this in https://github.com/python/cpython/pull/21574 On Tue, Jun 30, 2020 at 9:07 AM Luciano Ramalho <luciano@ramalho.org> wrote:
I was excited to learn about SupportsInt, SupportsFloat, and SupportsComplex protocols decorated with @runtime_checkable because I thought they bridged the gap between ABCs and typing protocol classes, allowing consistent type checks by static tools and at runtime.
However, I am unable to see how to use those classes in practice.
For example, SupportsComplex: I understand at runtime the @runtime_checkable decorator merely checks whether __complex__ exists in the type, but that is not a good predictor of how to use a numeric value.
Types that actually can be converted to complex fail the insinstance check with SupportsComplex. That's the case of built-in int and float, as well as NumPy integer and float types like float16 and uint8.
On the other hand, SupportsInt suggests that I can convert a complex to int, but in fact the int and float types implement __complex__ only to provide a better error message, according to Guido van Rossum in an earlier thread here.
isinstance(1+0j, SupportsInt) True int(1+0j) Traceback (most recent call last): ... TypeError: can't convert complex to int
The issue with SupportsInt also happens with SupportsFloat.
In addition, the way Mypy interprets these protocol classes is not the same as what we can see at runtime.
Given the above, what are recommended use cases for the runtime checkable SupportsInt, SupportsFloat, and SupportsComplex?
Cheers,
Luciano
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
participants (2)
-
Guido van Rossum -
Luciano Ramalho