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.richtho...@gmx.de> Datum: 23.06.17 01:08 (GMT+01:00) An: Ivan Levkivskyi <levkivs...@gmail.com> Cc: Markus Wissinger <markus.wissin...@gmail.com>, Python-Dev <python-dev@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 typing_inspect 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" <levkivs...@gmail.com> An: "Markus Wissinger" <markus.wissin...@gmail.com> Cc: Python-Dev <python-dev@python.org> Betreff: Re: [Python-Dev] PEP 544: Protocols - second round On 22 June 2017 at 10:44, Markus Wissinger <markus.wissin...@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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.de
_______________________________________________ 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
