Hi,

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 hints yet):
https://github.com/markuswissinger/ducktestpy

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.

Regards
Markus

2017-06-05 23:59 GMT+02:00 Guido van Rossum <guido@python.org>:
On Fri, Jun 2, 2017 at 3:10 PM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 1 June 2017 at 00:10, Guido van Rossum <guido@python.org> wrote:

On Wed, May 31, 2017 at 2:16 AM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 31 May 2017 at 00:58, Guido van Rossum <guido@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 focus
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.

+1

--
--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/markus.wissinger%40gmail.com