[Python-Dev] What's missing in PEP-484 (Type hints)

Dima Tisnek dimaqq at gmail.com
Tue May 12 16:04:56 CEST 2015

re: comprehension

Perhaps PEP can, at least, have a short list/summary of limitations?
I recall something was mentioned, but I can't find a section like that in PEP.

re: example

following https://github.com/JukkaL/mypy/blob/master/stubs/3.2/socket.py

# socket.pyi python2
class _socketobject:
    family = 0  # inferred from initializer (?)
    type = 0  # type: int  # explicit

# socket.pyi python3
class socket:
    family = AddressFamily.AF_UNSPEC  # inferred I presume?

    def settimeout(timeout: Union[int, float, None]) -> None: pass  #
negative arguments illegal
    timeout = -1.0  # yet, that's what you get by default (set None)

Perhaps, after all, socket module is a bad example.
I suppose you have a point that well-written modules are
self-documenting anyway...
Here's another try:

# _sqlite3.pyi python2 version
# warning, readonly: module allows reassignment, but you really shouldn't!
# instead use sqlite3.register_xxx functions
converters = {}  # type: Dict[str, Callable[[str], Any]]
adapters = {}  # type: Dict[Tuple[Type, SomethingInternal],
Callable[[Any], str]]

On 7 May 2015 at 17:39, Guido van Rossum <guido at python.org> wrote:
> On Thu, May 7, 2015 at 7:25 AM, Dima Tisnek <dimaqq at gmail.com> wrote:
>> On 30 April 2015 at 14:33, Steven D'Aprano <steve at pearwood.info> wrote:
>> > On Thu, Apr 30, 2015 at 01:41:53PM +0200, Dima Tisnek wrote:
>> >> # internal vs external
>> >> @intify
>> >> def foo() -> int:
>> >>     b = "42"
>> >>     return b  # check 1
>> >> x = foo() // 2  # check 2
>> >>
>> >> Does the return type apply to implementation (str) or decorated
>> >> callable (int)?
>> >
>> > I would expect that a static type checker would look at foo, and flag
>> > this as an error. The annotation says that foo returns an int, but it
>> > clearly returns a string. That's an obvious error.
>> Is this per PEP, or just a guess?
>> I think PEP needs to be explicit about this.
> The PEP shouldn't have to explain all the rules for type inferencing.
> There's a section "What is checked?" that says (amongst other things):
>   The body of a checked function is checked for consistency with the
>   given annotations.  The annotations are also used to check correctness
>   of calls appearing in other checked functions.
>> > Normally local variables will have their type inferred from the
>> > operations done to them:
>> >
>> >     s = arg[1:]  # s has the same type as arg
>> Good point, should be mentioned in PEP.
> Again, what do you want the PEP to say? I am trying to keep the PEP shorter
> than the actual code that implements the type checker. :-)
>> Technically, type can be empty list, mixed list or custom return type
>> for overloaded __getitem__ that accepts slices.
>> I'm sorry if I was not clear. My question was how should type of
>> ephemeral `x` be specified.
>> In other words, can types be specified on anything inside a comprehension?
> That's actually a good question; the PEP shows some examples of #type:
> comments in peculiar places, but there's no example using list
> comprehensions. Your best bet is to leave it to the type inferencer; if your
> comprehension is so complex that need to put type annotations on parts of
> it, you may be better off rewriting it as a regular for-loop, which offers
> more options for annotations.
>> Stub is better (required?) because it allows to specify types of
>> attributes that are not assigned in class scope, but that are expected
>> to be there as result of __init__ or because it's a C extension.
> Note that the PEP does not explicitly say whether the information of a stub
> might be *merged* with the information gleaned from the source code. The
> basic model is that if a stub is present the implementation source code is
> not read at all by the type checker (and, conversely, information from stubs
> is not available at all at runtime). But it is possible for some type
> checker to improve upon this model.
>> An example in PEP would be good.
> Can you give an example that I can edit and put in the PEP?
> --
> --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list