On Thu, 22 Apr 2021 at 11:21, Paul Moore <p.f.moore@gmail.com> wrote:
>
> On Thu, 22 Apr 2021 at 11:06, Chris Angelico <rosuav@gmail.com> wrote:
> >
> > Someone will likely correct me if this is inaccurate, but my
> > understanding is that that's exactly what you get if you just don't
> > give a type hint. The point of type hints is to give more information
> > to the type checker when it's unable to simply infer from usage and
> > context.
>
> Hmm, I sort of wondered about that as I wrote it. But in which case,
> what's the problem here? My understanding was that people were
> concerned that static typing was somehow in conflict with duck typing,
> but if the static checkers enforce the inferred duck type on untyped
> arguments, then that doesn't seem to be the case. Having said that, I
> thought that untyped arguments were treated as if they had a type of
> "Any", which means "don't type check".

Looks like it doesn't:

> cat .\test.py
def example(f) -> None:
    f.close()

import sys
example(12)
example(sys.stdin)
PS 12:00 00:00.009 C:\Work\Scratch\typing
> mypy .\test.py
Success: no issues found in 1 source file

What I was after was something that gave an error on the first call,
but not on the second. Compare this:

> cat .\test.py
from typing import Protocol

class X(Protocol):
    def close(self): ...

def example(f: X) -> None:
    f.close()

import sys
example(12)
example(sys.stdin)
PS 12:03 00:00.015 C:\Work\Scratch\typing
> mypy .\test.py
test.py:10: error: Argument 1 to "example" has incompatible type
"int"; expected "X"
Found 1 error in 1 file (checked 1 source file)