Hacker News Reader

Comment by mumblemumble | Hacker News Reader

I'm not sure I follow. Python's duck typing explicitly relies on its object-oriented features. I'm not sure that it's even possible to implement duck typing in a language that isn't object-oriented.

View on HN

When I talk about duck typing, I'm talking more about getattr and hasattr (explicit or implicit) rather than the everything-is-an-object structure under the hood. For example, you can invoke "foo()" on any thing no matter the type, and it'll work so long as you have "foo()" declared for the instance. You can't do that in many "OO-heavy" languages like C++ or Java. The advantage here is that in Python you don't have to explicit interfaces and base classes in order to achieve polymorphism.

You make a good point though-- the "duck typing" stuff is actually a consequence of Python using objects. Interesting: the "duck typing" paradigm should be able to be ported to other languages like Java then...

I am not a language expert, but Clojure (inspired by CLOS IIRC) does method resolution based on an arbitrary function that can ask any "is it a duck?" question of the arguments:

https://clojure.org/about/runtime_polymorphism

It's common for code to "choose" which method to call based on the class of the arguments, but it's also common to choose which method based on whether a particular key is in the hashmap, etc.

I suppose that this is edging dangerously close to starting a semantic argument, but I'd personally argue that ad-hoc polymorphism is a distinct concept from duck typing that just happens to have a lot of overlap in its use cases. One key distinction is that Clojure multimethods need to be explicitly declared somewhere, whereas duck typing is 100% implicit.

And in everyday Clojure usage the equivalent of Python attribute access is key access on maps, which is even more directly duck typed.

Reply on news.ycombinator.com