> 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@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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/kevinjacobconway%40gmail.com