Many Python programmers repeat that looking like a duck is much more important than if it’s really a duck. So, if you have an object passed to a function, then the class of the object is not important. The only important thing is if the passed object has a specific function, which you want to call.
If it walks like a duck and it quacks like a duck, then it must be a duck
What if it’s not? In the Wikipedia there is a more historical term, a Duck Test:
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
must is a very bad assumption. What if it’s not? Will the program blow up on production. The word
probably is a better assumption, but it’s also a very significant source of problems in many programs I observed. Sometimes something
looking like a duck is not a duck at all. It’s not even similar to a duck.
A string is not a number and a number is not a rectangle. So how come that in programming people claim these are the same things? Simple things will be simple. Unfortunately, every simple program tends to go in the direction of a much more twisted beast, right after you think about adding a new feature or two. Too often after such a change the result was having twisted ducks with four legs but without a head. The program was fine in most cases. Debugging was hard. It was much easier to start writing that from scratch. And then you will need to add a feature or two…
Should you care? Well, you always should. Unless you don’t care about the programs you are writing.