[Python-Dev] PEP 544: Protocols - second round

markus.wissinger markus.wissinger at gmail.com
Fri Jun 23 05:53:29 EDT 2017


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 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" <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>


More information about the Python-Dev mailing list