Comments on: ABCs

By: Hans Nowak

Hans Nowak — Sat, 07 Jun 2008 12:40:13 +0000

@Michael Campbell: That would indeed be great, but I doubt that it's ever going to happen, considering how vehemently the dev team defends str.join... But that would be a topic for another blog post. :-)

By: Michael Campbell

Michael Campbell — Sat, 07 Jun 2008 12:28:03 +0000

I anxiously await the complete reversal of how "correct" string.join(list) is when an iterable ABC gets created with .join(string) on it.

By: markus

markus — Sat, 07 Jun 2008 09:05:36 +0000

Io is definitely worth an extra look.

By: James

James — Sat, 07 Jun 2008 07:52:07 +0000

The PEP says "The built-in list and bytes types derive from MutableSequence." MutableSequence is a subclass of Sequence. So list would derive from more than object in Py3k, which I think might remove your main objection?

It looks to me like ABCs are just a convenient way to bundle together a series of 'promises' that a class makes about what methods it offers, like Java's interfaces. Unlike Java interfaces (and more like Ruby's modules), you can also put default implementations in the ABC, too. What seems to be the major innovation over what can be done in Python now, is that builtins will be placed under these new hierarchies.

By: Lennart Regebro

Lennart Regebro — Sat, 07 Jun 2008 05:42:41 +0000

Well, ABC's that are not inherited from should have been called interfaces. As it is now, the ABCs in Python 3 kinda mix those concepts a bit. It may or may not be a problem, I don't know, but intuitively I would have liked a greater separation between the two. But that might be since I've used zope.interfaces for a couple of years now, and like it. :-)

By: manuelg

manuelg — Sat, 07 Jun 2008 05:22:00 +0000

> It would, however, be perfectly possible for an abstract base class to have valid, working methods, to be used by classes inheriting from Foo. ... Apparently this isn't the case any longer.

From the PEP

> > Unlike Java's abstract methods or C++'s pure abstract methods, abstract methods as defined here may have an implementation. This implementation can be called via the super mechanism from the class that overrides it. This could be useful as an end-point for a super-call in framework using cooperative multiple-inheritance

If something is "list" enough to be used productively as a "list" (but inheriting from "list" would just leave us with a dangling, unused empty list object), now we have a canonical way to announce to the world to treat our object as a "list", without the overhead of subjecting it to a battery of tests.

We are all consenting adults here, so why be forced to inherit from a concrete class, just to throw away the "concrete" part. Abstract Base Classes are agreements among consenting adults.