I'm going to sign in as a partisan here. I firmly believe that Python is the worst language that people actually use.
DuckTyping is the most deeply misguided aspect of python. With the discover of Hindley-Milner type inference 40 and 30 years ago, this sort of sloth is simply inexcusable.
Pythonistas will say "Oh, I don't care if it's a duck or a swan, as long as it quacks." Guess what? You can treat function calls as a statement that an object is an instance of some typeclass and that typecheck that. With a sufficiently intelligent compiler/interpreter author this is transparent to the programmer.
With fairness, no you can't, not truly. Please point me to the version of HM the works with inheritance. Plus, due to stuff like __getattr__, the interpreter may not know until the method is called if it even exists.
It would be totally possible in python to write a class where when any arbitrary method is called on a class, a function is randomly generated and called, with a random number of arguments, etc. It doesn't even have to be consistent from call to call. How on earth would H-M type inference cope with that?
The point is you can't just bolt on H-M to a typical scripting language and expect it to work, like, at all. It's a pretty huge sea change, and it would warp the underlying language to the point where you'd just end up with some of non-lazy, non-pure Haskell.
Well, duck typing can still be statically checked, so I'd argue that dynamic typing is more misguided. That said, I do agree that duck typing is fundamentally flawed. I think swans actually don't quack, they honk, but so does a car. Here we can see a problem with both synonymous and homonymous verbs.
I think it comes down to namespacing: we use modules to prevent naming conflicts, allowing us to compose two modules, but if we do the same with objects their attributes conflict. In Haskell everything has a namespace — there are no methods, only functions — and type classes provide polymorphism without (henceforth) 'quack conflicts'.
Two terrible examples of quack conflicts from the Python standard library are '+' meaning both "add" and "append" (the latter being non-commutative), and the comparison operators '<', '<=', '>=', '>' actually meaning ⊂, ⊆, ⊇, ⊃ when dealing with sets.
DuckTyping is the most deeply misguided aspect of python. With the discover of Hindley-Milner type inference 40 and 30 years ago, this sort of sloth is simply inexcusable.
Pythonistas will say "Oh, I don't care if it's a duck or a swan, as long as it quacks." Guess what? You can treat function calls as a statement that an object is an instance of some typeclass and that typecheck that. With a sufficiently intelligent compiler/interpreter author this is transparent to the programmer.