[Python-Dev] PEP 544: Protocols - second round (original) (raw)
markus.wissinger markus.wissinger at gmail.com
Fri Jun 23 05:53:29 EDT 2017
- Previous message (by thread): [Python-Dev] PEP 544: Protocols - second round
- Next message (by thread): [Python-Dev] Extremely slow test modules
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
What I try to do is a new workflow:
- 'declare' types of method parameters by usage in a unit test. Therefore ensure the interface is obeyed inside.- publish the used types via hints to help callers of the method. -Do express all hints in test code. Do not insert any hints manually. Any type used in any test will result in a hint (with some clever exceptions). This requires some discipline while writing tests, but worked quite well already. I think I just realized pep544 protocols will not break that scheme, just make it a little more difficult to handle. I can create intermediate signatures that still contain superfluous subtypes and remove those only in the end when protocol hints are sure to exist. Thanks.Markus
-------- Ursprüngliche Nachricht --------Von: Stefan Richthofer <Stefan.Richthofer at gmx.de> Datum: 23.06.17 01:08 (GMT+01:00) An: Ivan Levkivskyi <levkivskyi at gmail.com> Cc: Markus Wissinger <markus.wissinger at gmail.com>, Python-Dev <python-dev at python.org> Betreff: Re: [Python-Dev] PEP 544: Protocols - second round
I am currently exploring a type hint generator that produces hints out of types used in unit tests.
Note that pytypes (https://github.com/Stewori/pytypes) already supports this. It can dump PEP 484 style stubfiles from runtime type observations (made via decorators or profiler hook).
isinstance(obj, T) and issubclass(Cls, T) already fail if T is a subscripted generic like List[int], so that again nothing new here. To check runtime subtyping with such types one can write a third party introspection tool based on typinginspect package on PyPI
There are public API functions in pytypes for isinstance and issubclass with support for most PEP 484 types, see https://github.com/Stewori/pytypes#is_of_typeobj-cls and https://github.com/Stewori/pytypes#is_subtypesubclass-superclass respectively. We also use them internally for pytypes' runtime typechecking features.
Unfortunately there is no release finalized yet, but it's mostly cleanup work and pip integration left to do. Hope to get a beta release done soon.
Best
-Stefan
Gesendet: Donnerstag, 22. Juni 2017 um 23:53 Uhr
Von: "Ivan Levkivskyi" <levkivskyi at gmail.com>
An: "Markus Wissinger" <markus.wissinger at gmail.com>
Cc: Python-Dev <python-dev at python.org>
Betreff: Re: [Python-Dev] PEP 544: Protocols - second round
On 22 June 2017 at 10:44, Markus Wissinger <markus.wissinger at gmail.com> wrote:
I have to admit I am not happy with separating the concepts of 'runtime' and 'static' types as implied by pep544.
This is not something new, already PEP 483 makes a clear distinction between types (a static concept) and classes (a runtime concept).
Failing isinstance/issubclass calls for protocols would hurt there. I understand that any type checker code that could provide isinstance functionality for pep544 protocols would rely on method signatures that my hint generator is just producing.
isinstance(obj, T) and issubclass(Cls, T) already fail if T is a subscripted generic like List[int], so that again nothing new here. To check runtime subtyping with such types one can write a third party introspection tool based on typing_inspect package on PyPI (which potentially might in future become an official wrapper for currently internal typing API).
--
Ivan
_______________________________________________ Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.de
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170623/589a4a5e/attachment.html>
- Previous message (by thread): [Python-Dev] PEP 544: Protocols - second round
- Next message (by thread): [Python-Dev] Extremely slow test modules
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]