<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 9, 2015 at 3:08 PM, Andrew Barnert via Python-ideas <span dir="ltr"><<a href="mailto:python-ideas@python.org" target="_blank">python-ideas@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div>On Sep 9, 2015, at 13:17, Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div dir="ltr">Jukka wrote up a proposal for structural subtyping. It's pretty good. Please discuss.<br><br><a href="https://github.com/ambv/typehinting/issues/11#issuecomment-138133867" target="_blank">https://github.com/ambv/typehinting/issues/11#issuecomment-138133867</a><br clear="all"></div></div></blockquote><div><br></div></span><div>Are we going to continue to have (both implicit and explicit) ABCs in collections.abc, numbers, etc., and also have protocols that are also ABCs and are largely parallel to them (and implicit at static checking time whether they're implicit or explicit at runtime) In typing? If so, I think we've reached the point where the two parallel hierarchies are a problem.</div></div></blockquote><div><br></div><div>I'm not proposing creating protocols for numbers or most collection types. I'd change some of the existing ABCs (mentioned in the proposal, including things like Sized) in typing into equivalent protocols, but they'd still support isinstance as before and would be functionally almost identical to the existing ABCs. I clarified the latter fact in the github issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div>Also, why are both the terminology and implementation so different from what we already have for ABCs? Why not just have a decorator or metaclass that can be added to ABCs that makes them implicit (rather than writing a manual __subclasshook__ for each one), which also makes them implicit at static type checking time, which means there's no need for a whole separate but similar notion?</div></div></blockquote><div><br></div><div>Protocol would use a metaclass that is derived from the ABC metaclass, and it would be similar to the Generic class that we already have. The reason why the proposal doesn't use an explicit metaclass or a class decorator is consistency. It's possible to define generic protocols by having Protocol[t, ...] as a base class, which is consistent with how Generic[...] works. The latter is already part of typing, and introducing a similar concept with a different syntax seems inelegant to me.</div><div><br></div><div>Consider a generic class:</div><div><br></div><div>class Bucket(Generic[T]): ...</div><div><br></div><div>Now we can have a generic protocol using a very similar syntax:</div><div><br></div><div>class BucketProtocol(Protocol[T]): ...</div><div> </div><div>I wonder how we'd use a metaclass or a class decorator to represent generic protocols. Maybe something like this:</div><div><br></div><div>@protocol[T]</div><div>class BucketProtocol: ...</div><div><br></div><div>However, this looks quite different from the Generic[...] case and thus I'd rather not use it. I guess if we'd have picked this syntax for generic classes it would make more sense:</div><div><br></div><div>@generic[T]</div><div>class Bucket: ...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div>I'm not sure why it's important to also have some times that are implicit at static type checking time but not at runtime, but if there is a good reason, that just means two different decorators/metaclasses/whatever (or a flag passed to the decorator, etc.). Compare:</div><div><br></div><div>Hashable is an implicit ABC, Sequence is an explicit ABC, Reversible is an implicit-static/explicit-runtime ABC. </div><div><br></div><div>Hashable is an implicit ABC and also a Protocol that's an explicit ABC, Sequence is an explicit ABC and not a Protocol, Reversible is a Protocol that's an explicit ABC.</div><div><br></div><div>The first one is clearly simpler; is there some compelling reason that makes the second one better anyway?</div></div></blockquote><div><br></div><div>I'm not sure if I fully understand what you mean by implicit vs. explicit ABCs (and the static/runtime distinction). Could you define these terms and maybe give some examples of each? Note that in my proposal a protocol is just a kind of ABC, as GenericMeta is a subclass of ABCMeta and protocol would have a similar metaclass (or maybe even the same one), even though I'm not sure if I explicitly mentioned that. Every protocol is also an ABC.</div><div> </div><div>Jukka</div></div></div></div>