According to PEP 484 all missing annotations in checked functions should be
handled as Any. Any is compatible with all types.
I think from a technical standpoint it should be possible to infer protocols
for arguments for most functions, but there are some edge cases where this
would not be possible, making it impractical to make this the default behavior.
Having an annotation to make a type checker infer a protocol would be
interesting though.
For example:
def f(x: int): ...
def g(x: str): ...
def main(t):
if t[0] == 'version':
f(t[1])
elif t[0] == 'name':
g(t[1])
You could statically type t as Union[Tuple[Literal['version'], int],
Tuple[Literal['name'], str]], but inferring a Protocol for this would be either
very hard or even impossible, especially with even more complex conditions.
Adrian Freund
On April 22, 2021 1:04:11 PM GMT+02:00, Paul Moore <p.f.mo...@gmail.com> wrote:
>On Thu, 22 Apr 2021 at 11:21, Paul Moore <p.f.mo...@gmail.com> wrote:
>>
>> On Thu, 22 Apr 2021 at 11:06, Chris Angelico <ros...@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)
>
>Paul
>_______________________________________________
>Python-Dev mailing list -- python-dev@python.org
>To unsubscribe send an email to python-dev-le...@python.org
>https://mail.python.org/mailman3/lists/python-dev.python.org/
>Message archived at
>https://mail.python.org/archives/list/python-dev@python.org/message/54C6G2JLYYD6B37J5KVKPCKSQDCGLRKA/
>Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/M4XDZUPWKPGRO3NF5VONG22YHOHAYZCM/
Code of Conduct: http://python.org/psf/codeofconduct/
