Many values trigger warning even when you accept SupportsInt

[sametmax]

When linting this program with mypy:

from typing import SupportsInt

class Bar:

    def __int__(self):
        return 1

def foo(a: SupportsInt):
    return int(a)

foo('1')
foo(True)
foo(1)
foo(1.1)
foo(Bar())

I got the following errors:

test.py:12: error: Argument 1 to "foo" has incompatible type "str"; expected "SupportsInt"
test.py:16: error: Argument 1 to "foo" has incompatible type "Bar"; expected "SupportsInt"

I was expecting that anything accepted but int() would be accepted by something hinting for SupportsInt. Is my expectation wrong or is this a bug?

If my expectations are wrong, how would I create the same signature as int()?

[Michael0x2a]

To fix foo(Bar()) not being accepted, you need to change Bar so it extends SupportInt -- do class Bar(SupportsInt): ....

(The reason why mypy needs you to extend SupportsInt instead of just automatically detecting that any class with an __int__ method matches the SupportsInt interface is because mypy doesn't yet support structural typing -- see python/typing#11 for details)

That said, it seems like str doesn't actually have an __int__ method, so it's seems correct to me that it doesn't extend SupportsInt.

You can find the type signature for int on the repo for typeshed. For Python 3, it's:

class int(SupportsInt, SupportsFloat, SupportsAbs[int]):
    def __init__(self, x: Union[SupportsInt, str, bytes] = ..., base: int = ...) -> None: ...

[sametmax]

The code I want to hint, I don't have access to the class I'm accepting, so I can't make it subclass anything.

Is mypy planning to support structural typing in the future ?

[gvanrossum]

Structural typing is on the road map, but we don't have a specific plan or timeline yet.

I wonder if it would be simple for mypy to hard-code some structural typing for the standard typing.SupportsXxx classes. In some places it uses structural checks, e.g. in for and with statements anything that has __iter__ or __enter__/__exit__ respectively is accepted, so it's possible to do with enough willpower.

[NYKevin]

For the record, it is not always possible to inherit from typing.SupportsXxx because, in sufficiently complicated instances which I have not (yet) managed to reduce to a minimal example, this causes isinstance() checking to break ("Protocols cannot be used with isinstance().").

Full context in which this fails to work (specifically, if you add typing.SupportsXxx to the superclasses of _RealTag, the highlighted isinstance() check breaks; tested with Python 3.5.2). Note that these classes are already using the Python numeric tower and are perfectly happy with it (give or take a few nits I am currently working on cleaning up). But since PEP 484 seems to hate the numeric tower, there's little I can do here besides throwing # type: ignore comments everywhere.

The easiest way to reproduce the issue is to checkout the aforementioned code, add the superclasses, and run unit tests (python3 -m unittest discover -s ./tests -t . in the repo root).

I also tried to fool it into doing what I wanted with typing.SupportsXxx.register(_RealTag), but Mypy doesn't seem to recognize that either.

[ilevkivskyi]

This now works correctly, only str gives an error, since all builtin protocols are declared as protocols in typeshed.