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

[Kevin Conway]

> Some of the possible options for the title are
It seems like you're talking about something most other languages would
refer to as "Interfaces". What is unique about this proposal that would
call for not using the industry standard language?

> Type-hints should not have runtime semantics, beyond those that they have
as classes
>  lots of code uses isinstance(obj, collections.abc.Iterable) and similar
checks with other ABCs
Having interfaces defined as something extended from abc doesn't
necessitate their use at runtime, but it does open up a great deal of
options for those of us who want to do so. I've been leveraging abc for a
few years now to implement a lightweight version of what this PEP is
attempting to achieve (https://github.com/kevinconway/iface). Once you
start getting into dynamically loaded plugins you often lose the ability to
strictly enforce the shape of the input until runtime. In those cases, I've
found it exceedingly useful to add 'isinstance' and 'issubbclass' as
assertions to input of untrusted types for the tests and non-production
deployments. For a perf boost in prod you can throw the -O flag and strip
out the assertions to remove the runtime checks. I've found that to be a
valuable pattern.

On Sun, May 28, 2017 at 8:21 AM Ivan Levkivskyi <levkivskyi at gmail.com>
wrote:

> Thanks everyone for interesting suggestions!
>
> @Antoine @Guido:
> Some of the possible options for the title are:
> * Protocols (structural subtyping)
> * Protocols (static duck typing)
> * Structural subtyping (static duck typing)
> which one do you prefer?
>
> @Nick:
> Yes, explicit imports are not necessary for static type checkers (I will
> add a short comment about this).
>
> @Mark:
> I agree with Guido on all points here. For example,
> collections.abc.Iterable is already a class,
> and lots of code uses isinstance(obj, collections.abc.Iterable) and
> similar checks with other ABCs
> (also in a structural manner, i.e. via __subclasshook__). So that
> disabling this will case many breakages.
> The question of whether typing.Iterable[int] should be a class is
> independent (orthogonal) and
> does not belong to this PEP.
>
> --
> 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/kevinjacobconway%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170528/954784bd/attachment.html>