​

On Sat, Jun 24, 2017 at 12:42 PM, Koos Zevenhoven <k7hoven@gmail.com> wrote:

There has been some discussion here and there concerning the differences between runtime types and static types (mypy etc.). What I write below is not really an idea or proposal---just a perspective, or a topic that people may want to discuss. Since the discussion on this is currently very fuzzy and scattered and not really happening either AFAICT (I've probably missed many discussions, though). Anyway, I thought I'd give it a shot:

Regarding runtime types and isinstance, let's look at the Iterable[int] example. For this case, there are a few options:

1) Don't implement isinstance

This is problematic for runtime uses of annotations.

2) isinstance([1, '2', 'three'], Iterable[int]) returns True

This is in fact now the case. This is ok for many runtime situations, but lacks precision compared to the static version. One may want to distinguish between Iterable[int] and Iterable[str] at runtime (e.g. the multidispatch example above).

3) Check as much as you can at runtime

There could be something like Reiterable, which means the object is not consumed by iterating over it, so one could actually check if all elements are instances of int. This would be useful in some situations, but not available for every object. Furthermore, the check could take an arbitrary amount of time so it is not really suitable for things like multidispatch or some matching constructs etc., where the performance overhead of the type check is really important.

4) Do a deeper check than in (2) but trust the annotations

For example, an instance of a class that has a method like

def __iter__(self) -> Iterator[int]:

    some code

could be identified as Iterable[int] at runtime, even if it is not guaranteed that all elements are really integers.

On the other hand, an object returned by 

def get_ints() -> Iterable[int]:

    some code

does not know its own annotations, so the check is difficult to do at runtime. And of course, there may not be annotations available.

5) Something else?

And what about PEP544 (protocols), which is being drafted? The PEP seems to aim for having type objects that represent duck-typing protocols/interfaces. Checking whether a protocol is implemented by an object or type is clearly a useful thing to do at runtime, but it is not really clear if isinstance would be a guaranteed feature for PEP544 Protocols.

So one question is, is it possible to draw the lines between what works with isinstance and what doesn't, and between what details are checked by isinstance and what aren't? -- Or should insinstance be reserved for a more limited purpose, and add another check function, say `implements(...)`, which would perhaps guarantee some answer for all combinations of object and type?