>From the PEP: > The problem with them is that a class has to be explicitly marked to support them, which is unpythonic and unlike what one would normally do in idiomatic dynamically typed Python code. > The same problem appears with user-defined ABCs: they must be explicitly subclassed or registered. Neither of these statements are entirely true. The semantics of `abc` allow for exactly the kind of detached interfaces this PEP is attempting to provide. The `abc.ABCMeta` provides the `__subclasshook__` which allows a developer to override the default check of internal `abc` registry state with virtually any logic that determines the relationship of a class with the interface. The prior art I linked to earlier in the thread uses this feature to generically support `issubclass` and `isinstance` in such a way that the PEPs goal is achieved.
> The intention of this PEP is to solve all these problems by allowing users to write the above code without explicit base classes in the class definition As I understand this goal, you want to take what some of us in the community have been building ourselves and make it canonical via the stdlib. What strikes me as odd is that the focus is on 3rd party type checkers first rather than introducing this as a feature of the language runtime and then updating the type checker contract to make use of it. I see a mention of the `isinstance` check support in the postponed/rejected ideas, but the only rationale given for it being in that category is, generally, "there are edge cases". For example, the PEP lists this as an edge case: >The problem with this is instance checks could be unreliable, except for situations where there is a common signature convention such as Iterable However, the sample given demonstrates precisely the expected behavior of checking if a concrete implements the protocol. It's unclear why this sample is given as a negative. The other case given is: > Another potentially problematic case is assignment of attributes after instantiation Can you elaborate on how type checkers would not encounter this same issue? If there is a solution to this problem for type checkers, would that same solution not work at runtime? Also, it seems odd to use a custom initialize function rather than `__init__`. I don't think it was intentional, but this makes it seem like a bit of a strawman that doesn't represent typical Python code. > Also, extensive use of ABCs might impose additional runtime costs. I'd love to see some data around this. Given that it's a rationale for the PEP I'd expect to see some numbers behind it. For example, is memory cost of directly registering implementations to abc linear or worse? What is the runtime growth pattern of isinstance or issubclass when used with heavily registered or deeply registered abc graphs and is it different than those calls on concrete class hierarchies? Does the cost affect anything more than the initial evaluation of the code or, in the absence of isinstance/issubclass checks, does it continue to have an impact on the runtime? On Mon, May 29, 2017 at 5:41 AM Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 28 May 2017 at 19:40, Guido van Rossum <gu...@python.org> wrote: > >> On Sun, May 28, 2017 at 8:27 AM, Ivan Levkivskyi <levkivs...@gmail.com> >> wrote: >> > [...] > >> Regarding the title, I'd like to keep the word Protocol in the title too, >> so I'd go with "Protocols: Structural subtyping (duck typing)" -- hope >> that's not too long to fit in a PEP title field. >> > > OK, this looks reasonable. > > >> >> > 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 >>>> >>> >>> IIUC this is not the main goal of the PEP, the main goal is to provide >>> support/standard for _static_ structural subtyping. >>> Possibility to use protocols in runtime context is rather a minor bonus >>> that exists mostly to provide a seamless transition >>> for projects that already use ABCs. >>> >> >> Is something like this already in the PEP? It deserves attention in one >> of the earlier sections. >> > > Yes, similar discussions appear in "Rationale and Goals", and "Existing > approaches to structural subtyping". Maybe I need to polish the text there > adding more focus on static typing. > > -- > 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/archive%40mail-archive.com
