[Python-Dev] PEP 484 (Type Hints) -- the next draft is here
The PEP 484 authors (Jukka, Łukasz and I) have a new draft ready. This time we're posting to python-dev. While we don't have all details totally sorted out, it's a lot closer. We have a BDFL-Delegate (Mark Shannon), and we've worked out a variety of issues at PyCon. Our hope remains that we'll get the typing.py module added to CPython 3.5 before beta 1 goes out (May 24). Below is a list of key changes since the draft posted to python-dev on March 20 (for more details see https://github.com/ambv/typehinting/commits/master/pep-0484.txt) and the full text of the PEP. The new draft is also in the peps repo ( https://hg.python.org/peps/file/tip/pep-0484.txt) and will soon be on python.org (https://www.python.org/dev/peps/pep-0484/ -- give it 10-30 minutes). As always, between draft postings the PEP text is updated frequently by the authors in a dedicated GitHub repo (https://github.com/ambv/typehinting), and many detailed discussions are found in the issue tracker there ( https://github.com/ambv/typehinting/issues). The typing.py module also lives in that repo ( https://github.com/ambv/typehinting/tree/master/prototyping). Key changes since 20-Mar-2015 draft -- Generics: - Properly specify generics and type variables. - Add covariant/contravariant flags to TypeVar(). Type specifications: - Define type aliases. - Kill Undefined. - Better specification of `# type:` comments. Specifics: - Add Generator (a generic type describing generator objects) - Document get_type_hints(). Stubs: - Only .pyi is a valid extension for stub files. - Add discussion of third-party stubs (see issue #84). Process: - Mark Shannon is now BDFL-Delegate. - Add section on PEP Development Process, with github links. Other: - Mention the __future__ proposal (a separate PEP to be developed). - Lots of editing; remove some sections that didn't specify anything. Full PEP text -- PEP: 484 Title: Type Hints Version: $Revision$ Last-Modified: $Date$ Author: Guido van Rossum , Jukka Lehtosalo < jukka.lehtos...@iki.fi>, Łukasz Langa BDFL-delegate: Mark Shannon Discussions-To: Python-Dev Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 29-Sep-2014 Post-History: 16-Jan-2015,20-Mar-2015,17-Apr-2015 Resolution: Abstract This PEP introduces a standard syntax for type hints using annotations (PEP 3107) on function definitions. For example, here is a simple function whose argument and return type are declared in the annotations:: def greeting(name: str) -> str: return 'Hello ' + name While these annotations are available at runtime through the usual ``__annotations__`` attribute, *no type checking happens at runtime*. Instead, the proposal assumes the existence of a separate off-line type checker which users can run over their source code voluntarily. Essentially, such a type checker acts as a very powerful linter. The proposal is strongly inspired by mypy [mypy]_. For example, the type "sequence of integers" can be written as ``Sequence[int]``. The square brackets mean that no new syntax needs to be added to the language. The example here uses a custom class ``Sequence``, imported from a pure-Python module ``typing``. The ``Sequence[int]`` notation works by implementing ``__getitem__()`` in the metaclass. The type system supports unions, generic types, and a special type named ``Any`` which is consistent with (i.e. assignable to and from) all types. This latter feature is taken from the idea of gradual typing. Gradual typing and the full type system are explained in PEP 483. Other approaches from which we have borrowed or to which ours can be compared and contrasted are described in PEP 482. Rationale and Goals === PEP 3107 added support for arbitrary annotations on parts of a function definition. Although no meaning was assigned to annotations then, there has always been an implicit goal to use them for type hinting, which is listed as the first possible use case in said PEP. This PEP aims to provide a standard syntax for type annotations, opening up Python code to easier static analysis and refactoring, potential runtime type checking, and performance optimizations utilizing type information. Of these goals, static analysis is the most important. This includes support for off-line type checkers such as mypy, as well as providing a standard notation that can be used by IDEs for code completion and refactoring. Non-goals - While the proposed typing module will contain some building blocks for runtime type checking -- in particular a useful ``isinstance()`` implementation -- third party packages would have to be developed to implement specific runtime type checking functionality, for example using decorators or metaclasses. Using type hints for performance optimizations is left as an exercise for the reader. It should also be emphasized that Python will remain a dynamically typed language, and
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
Guido van Rossum schrieb am 17.04.2015 um 23:58: > The ``typing`` module defines the ``Generator`` type for return values > of generator functions. It is a subtype of ``Iterable`` and it has > additional type variables for the type accepted by the ``send()`` > method and the return type of the generator: > > * Generator, used as ``Generator[yield_type, send_type, return_type]`` Is this meant to accept only Python generators, or any kind of object that implements the coroutine protocol? I'm asking because asyncio currently suffers from an annoying type check here, so I'd like to avoid that this problem keeps popping up again in other places. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
(Also, there might be some interaction with PEP 492 here, which also tweaks the definition of generators.) On Sat, Apr 18, 2015 at 9:38 AM, Guido van Rossum wrote: > That's a good question. We *could* make it so that you can subclass > Generator and instantiate the instances; or we could even make it do some > structural type checking. (Please file a pull request or issue for this at > github.com/ambv/typehinting .) But perhaps we should also change asyncio? > What check are you talking about? > > On Fri, Apr 17, 2015 at 10:35 PM, Stefan Behnel > wrote: > >> Guido van Rossum schrieb am 17.04.2015 um 23:58: >> > The ``typing`` module defines the ``Generator`` type for return values >> > of generator functions. It is a subtype of ``Iterable`` and it has >> > additional type variables for the type accepted by the ``send()`` >> > method and the return type of the generator: >> > >> > * Generator, used as ``Generator[yield_type, send_type, return_type]`` >> >> Is this meant to accept only Python generators, or any kind of object that >> implements the coroutine protocol? I'm asking because asyncio currently >> suffers from an annoying type check here, so I'd like to avoid that this >> problem keeps popping up again in other places. >> >> Stefan >> >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (python.org/~guido) > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
That's a good question. We *could* make it so that you can subclass Generator and instantiate the instances; or we could even make it do some structural type checking. (Please file a pull request or issue for this at github.com/ambv/typehinting .) But perhaps we should also change asyncio? What check are you talking about? On Fri, Apr 17, 2015 at 10:35 PM, Stefan Behnel wrote: > Guido van Rossum schrieb am 17.04.2015 um 23:58: > > The ``typing`` module defines the ``Generator`` type for return values > > of generator functions. It is a subtype of ``Iterable`` and it has > > additional type variables for the type accepted by the ``send()`` > > method and the return type of the generator: > > > > * Generator, used as ``Generator[yield_type, send_type, return_type]`` > > Is this meant to accept only Python generators, or any kind of object that > implements the coroutine protocol? I'm asking because asyncio currently > suffers from an annoying type check here, so I'd like to avoid that this > problem keeps popping up again in other places. > > Stefan > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
Guido van Rossum schrieb am 18.04.2015 um 18:38: > That's a good question. We *could* make it so that you can subclass > Generator and instantiate the instances; or we could even make it do some > structural type checking. (Please file a pull request or issue for this at > github.com/ambv/typehinting .) Done: https://github.com/ambv/typehinting/issues/89 > But perhaps we should also change asyncio? > What check are you talking about? https://hg.python.org/cpython/file/439517000aa2/Lib/asyncio/coroutines.py#l169 The current (3.5alpha) check in iscoroutine() is an instance check against _COROUTINE_TYPES, which contains types.GeneratorType and another wrapper type. It excludes objects that implement the coroutine protocol without being Python generators, e.g. Cython compiled generators, which mimic the Python generator interface without having byte code in them (meaning, they are not C-level compatible with Python generators). I'm sure the same applies to other compilers like Numba or Nuitka. Supporting asyncio in recent Python releases thus means monkey patching _COROUTINE_TYPES and adding another type to it. Given that it's not a public interface, this seems a bit fragile. It also seems that this code only appeared somewhere in the 3.4.x release series. Older versions were even worse and did a straight call to inspect.isgenerator() in their iscoroutine() function, which means that the whole function needed to be replaced and wrapped (and even that didn't fix all places where inspect was used). I guess I should open a (CPython) ticket for this topic, too... Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
Stefan Behnel schrieb am 18.04.2015 um 19:39: > Guido van Rossum schrieb am 18.04.2015 um 18:38: >> That's a good question. We *could* make it so that you can subclass >> Generator and instantiate the instances; or we could even make it do some >> structural type checking. (Please file a pull request or issue for this at >> github.com/ambv/typehinting .) >> >> But perhaps we should also change asyncio? >> What check are you talking about? > > https://hg.python.org/cpython/file/439517000aa2/Lib/asyncio/coroutines.py#l169 > > The current (3.5alpha) check in iscoroutine() is an instance check against > _COROUTINE_TYPES, which contains types.GeneratorType and another wrapper > type. It excludes objects that implement the coroutine protocol without > being Python generators, e.g. Cython compiled generators, which mimic the > Python generator interface without having byte code in them (meaning, they > are not C-level compatible with Python generators). I'm sure the same > applies to other compilers like Numba or Nuitka. Supporting asyncio in > recent Python releases thus means monkey patching _COROUTINE_TYPES and > adding another type to it. Given that it's not a public interface, this > seems a bit fragile. > > It also seems that this code only appeared somewhere in the 3.4.x release > series. Older versions were even worse and did a straight call to > inspect.isgenerator() in their iscoroutine() function, which means that the > whole function needed to be replaced and wrapped (and even that didn't fix > all places where inspect was used). Hmm, looks like I remembered it incorrectly. Monkey patching the inspect module is required in both versions as it's being used in more places, especially the coroutine wrappers. I'll see how I can get it working with Cython and then open tickets for it. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here
Maybe the thing to fix then is the inspect module, not asyncio? Anyway, let is know via tickets. On Sat, Apr 18, 2015 at 12:29 PM, Stefan Behnel wrote: > Stefan Behnel schrieb am 18.04.2015 um 19:39: > > Guido van Rossum schrieb am 18.04.2015 um 18:38: > >> That's a good question. We *could* make it so that you can subclass > >> Generator and instantiate the instances; or we could even make it do > some > >> structural type checking. (Please file a pull request or issue for this > at > >> github.com/ambv/typehinting .) > >> > >> But perhaps we should also change asyncio? > >> What check are you talking about? > > > > > https://hg.python.org/cpython/file/439517000aa2/Lib/asyncio/coroutines.py#l169 > > > > The current (3.5alpha) check in iscoroutine() is an instance check > against > > _COROUTINE_TYPES, which contains types.GeneratorType and another wrapper > > type. It excludes objects that implement the coroutine protocol without > > being Python generators, e.g. Cython compiled generators, which mimic the > > Python generator interface without having byte code in them (meaning, > they > > are not C-level compatible with Python generators). I'm sure the same > > applies to other compilers like Numba or Nuitka. Supporting asyncio in > > recent Python releases thus means monkey patching _COROUTINE_TYPES and > > adding another type to it. Given that it's not a public interface, this > > seems a bit fragile. > > > > It also seems that this code only appeared somewhere in the 3.4.x release > > series. Older versions were even worse and did a straight call to > > inspect.isgenerator() in their iscoroutine() function, which means that > the > > whole function needed to be replaced and wrapped (and even that didn't > fix > > all places where inspect was used). > > Hmm, looks like I remembered it incorrectly. Monkey patching the inspect > module is required in both versions as it's being used in more places, > especially the coroutine wrappers. I'll see how I can get it working with > Cython and then open tickets for it. > > Stefan > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
