I think this is interesting, but I think the way Python is described is slightly wrong? In Python, you don't need to define a protocol to support duck typing, you can just implement the same behavior. Protocols don't have a function outside of static typing (they don't influence any program behavior at run-time.)
I guess it depends on whether you consider duck typing to be "passes the static type checker" or "it works the same".
"Because Animal is a Protocol, any class that defines feed() becomes an Animal"
is slightly incorrect.
By default, protocols are only relevant for static type analysis, but you _can_ enable runtime instance checking using the @runtime_checkable decorator.
(So you can do "if isinstance(foo, Animal):...", but AFAIK this decorator comes with a performance penalty)
Protocols allow you to explicitly declare a class implements them by making them a base of the class, but do not require it. Every class that implements the specification of the protocol is usable where the protocol is specified, not only those explicitly marked with it. Python didn't make c#'s doofy mistake of requiring the programmer to explicitly annotate everything. So, not every implementer of the protocol will have isinstance be true.
That is correct, but the @runtime_checkable decorator (which goes on the class that defines the protocol, e.g. "Animal" in the blog's example) makes it so that any class that implements the required methods (e.g. Rabbit) also passes the isinstance test (so isinstance(Rabbit, Animal) does actually return True, even though Rabbit is not defined as a subclass of Animal, i.e. NOT class Rabbit(Animal) !)
Whether it makes sense to use that is a different question, but it is possible :)
it looks rather gross to me, and more dangerous than useful. why bother with a half check that can only see if the methods/attributes are present, but that can't guarantee they do what you need? better to not offer such a check at all, I should think.
but I'm not a fan of a great number of things python has been doing over the last some years.
if you were going to do such a thing (perhaps to allow type-safe callbacks from untyped code), I would think a wrapper would be the proper method, that checks the incoming parameters and the outgoing return value, raising an error if those are of the wrong sorts, and possibly further wrapping if something was declared to fit a protocol.
I can program in a dozen languages or so, so I'm not coming at it from some place of knowing python and complaining about C#. There's plenty to complain about in python's typing.
Having to hand annotate classes to indicate interface membership instead of just writing classes and letting the compiler perform structural analysis depending on their usage is annoying.
What happens when member names collide and you match an interface you shouldn’t have? It’s an issue even in Go, which, unlike Python, has a usable type system.
I suppose if you were so unfortunate as to have two interfaces name the same function with different expectations on what it does, you'd end up having to use an intermediate object to wrap around your base one, to ensure it matches the required interface, possibly adding a helper to wrap the current object for convenience at callsites.
In C#, you would instead define a method and specify the name of the interface in order to override the method it receives to be different from the base method that is experiencing the conflict.
I know this is a real issue, but I don't think this is excessively common for either language.
And the real answer for both would be to rename/prefix the names in the interfaces so that they aren't conflicting in the first place, if you have the ability to do so :-)
There are certainly always trade offs when building something.
I guess it depends on whether you consider duck typing to be "passes the static type checker" or "it works the same".