Hacker News Reader

Comment by yellowapple | Hacker News Reader

> Abstract base classes require everything to extend from a base-level object, and also inherit it's default implementations. This is a nominal (name-based) mechanism.

The very definition of an abstract base class precludes the existence of (meaningful) implementations. If the base class has implementations for the methods expected to be overridden (beyond no-ops or throwing some exception around the lack of an implementation), then it is definitionally not abstract.

That is: a protocol and an abstract class achieve the same thing: they declare the existence of methods, and defer implementation of those methods to implementations / child classes (respectively).

Interfaces are great, but if you have multiple inheritance as your hammer (as you do in Python), then it's perfectly reasonable for abstract class inheritance to be your nail.

View on HN

(meaningful) isn't as much a get-of-out-jail clause here as you suggest, if I understand correctly. Requiring implementations at all, even if they are broken, moves the time when you find out about a missing definition to runtime, rather than being statically determined at typecheck time.

If the not-overriden method isn't commonly called, it's possible for the non-meaningful / raise an exception version to make it to production. Not so if the error happens at typecheck time.

That is true. However, other linters (e.g., pylint) will check a class satisfies its interface. IIRC, the runtime error for non-implemented abstract methods happens at instantiation time, rather than when said missing method call is attempted.

Right, but that's a problem more fundamental to Python and applicable far beyond the "abstract" classes hacked onto it. That is: if the methods were missing entirely, you'd have the same problem, since Python (without the help of external tools) doesn't make any attempt to validate these things at (bytecode) compile time.

> The very definition of an abstract base class precludes the existence of (meaningful) implementations.

No, it doesn't. It precludes meaningful implementation of the complete interface, of course, but it doesn't preclude meaningful implementation for some methods, which depend on the other methods do which meaningful implementations are not provided.

Right, but those methods which are implemented are not in the set of methods intended for descendant classes to override. If they are in that set, at all, then the base class is by definition not abstract.

The fundamental issue is that Python doesn't really have a way to enforce this, so there's ultimately no such thing as an abstract class in Python - there are only classes that act like they're abstract (by replacing all implementations of meant-to-be-overridden methods with no-ops or thrown exceptions).

> The fundamental issue is that Python doesn't really have a way to enforce this

When (as to make this even worth discussing, one must) one includes the typecheckers (which are technically external) in “Python”, that's not true; both mypy and pyright enforce that abstract classes (either those explicitly declared as abcs, or derived classes with any non-overridden declared-as-abstract methods) cannot be instantiated.

Reply on news.ycombinator.com