You're referring to duck typing, which to me contradicts the Zen of Python: Explicit is better than implicit.

> Slower?

Yes, overall the language is slower than PHP. It's not a bad thing, just the result of benchmarks. It doesn't mean one should stop writing Python.

No, I'm not referring to duck typing. An abstract base class enforces the interface. Explicitly.

Some benchmarks might be slower, but I don't know anyone doing high-performance computing with PHP. I do see the topic at Python conferences.

abstract base class != interface

Let me help you two out:

ABCs are like interfaces in they can be used to enforce properties (like the presence of particular functions) of a class that extends/impliments them; BUT, interfaces can also be used to enforce a particular variable always refers to something with certain properties (without worrying about what it is concretely).

Right, they're even better than Interfaces: both a contract and a partial implementation. No need for an "Interface" when you've got ABCs.

I see what you mean, but to me abstract classes are distinct from interfaces. Abstract class answers the question "what an object is?", whereas an interface is about what the object can do.

The distinction between what an object is and what an object can do is an artifact of bad object modelling (specifically, single inheritance OOP.) Any “can do” set has an exactly corresponding “is a thing that can do” set, so there is no logical need for different constructs to model “is” sets and “can do” sets.

Sounds like a controversial statement and I'm not sure how universal true this is. I'll give it a thought. Thank you.

Another way of explaining this is that Interfaces are Java's way to compensate for the lack of multiple inheritance.

There's more than one variety of inheritance. Both Python and Java chose implementation-inheritance, meaning that the children get to use not only the interface, but also the implementation of the parent.

For some reason, I'm not quite sure why, the Java folks thought that multiple implementation-inheritance would cause too many problems. They still recognized it's useful, so they provided a 2nd form of inheritance that supports multiple parents, interface-inheritance.

There are more varieties of inheritance that a language could choose, for example, prototypes like JavaScript.

Yes, I'm familiar with all of that, but isn't the Diamond of Death [1] is the exact reason why they did it?

[1] https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamo...

People read left to right. That solves all the trivial problems. The harder problems were always vocabulary problems not programming problems.

The trouble is that English, and other human languages, have never been as clear or specific as we assume they are when we start writing code. For example, what is a bird? It's a thing that flies? Oh, ostrich, penguin...

All these supposed OOP inheritance problems aren't unique to inheritance but to the translation of human language to programming. There's no need to exclude multiple inheritance, because nearly every aspect of programming is afflicted.

That distinction is unnecessary.