[Python-Dev] PEP 544: Protocols - second round
markus.wissinger at gmail.com
Thu Jun 22 04:44:12 EDT 2017
I have to admit I am not happy with separating the concepts of 'runtime'
and 'static' types as implied by pep544.
I am currently exploring a type hint generator that produces hints out of
types used in unit tests. It debugs the tests and collects the parameter
types of call and return events. It ignores a type when a supertype is
present. 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.
proof of concept implementation (writes method docstrings, no pep484 type
This is currently just some personal project that some of you will consider
a strange idea. I just want to mention that this use case might not play
well together with pep544.
2017-06-05 23:59 GMT+02:00 Guido van Rossum <guido at python.org>:
> On Fri, Jun 2, 2017 at 3:10 PM, Ivan Levkivskyi <levkivskyi at gmail.com>
>> On 1 June 2017 at 00:10, Guido van Rossum <guido at python.org> wrote:
>>> On Wed, May 31, 2017 at 2:16 AM, Ivan Levkivskyi <levkivskyi at gmail.com>
>>>> On 31 May 2017 at 00:58, Guido van Rossum <guido at python.org> wrote:
>>>> Thank you for very detailed answers! I have practically nothing to add.
>>>> It seems to me that most of the Kevin's questions stem from unnecessary
>>>> on runtime type checking. Here are two ideas about how to fix this:
>>>> * Add the word "static" somewhere in the PEP title.
>>> So the title could become "Protocols: Static structural subtyping (duck
>>> typing)" -- long, but not record-setting.
>> I am thinking about "Protocols: Structural subtyping (static duck
>> typing)". The reason is that subtyping is already a mostly static concept
>> (in contrast to subclassing),
>> while duck typing is typically associated with the runtime behaviour.
>> This might seem minor, but this version of the title sounds much more
>> naturally to me.
> --Guido van Rossum (python.org/~guido)
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev