On Thu, Apr 22, 2021 at 4:11 AM Paul Moore <p.f.moore@gmail.com> wrote:
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)
Do note that this is only based on what mypy does, not necessarily what all Python type checkers do. I.e. it's quite possible pytype, pyre, or pyright infer more (especially https://pypi.org/project/pytype/ since they specifically say they infer types).