If we make ABCMeta.register() return the registered class, like atexit.register() does for the registered function, we can then use it as a decorator:

Now:

class Foo:
    ...
ABarC.register(Foo)

With this change:

@ABarC.register
class Foo:
    ...

The only problem this would cause is in code that relies on ABCMeta.register() to return None; I can't think of a reason anyone would rely on this, but...

Looks like a good idea to me.

Thanks for the report and patch.  Some comments:


+        """Register a virtual subclass of an ABC. Returns the said subclass."""
Should be “Return”, for consistency.

+        return subclass # For usage as a decorator
I’d move that to the docstring.

Can you edit the docs (remember to use the versionchanged directive) too?

Ok, edited the docs too; hope I did everything right...

Edited your patch to fix some nits.  If there is no opposition, I’ll commit this to py3k when 3.2 is out.

+1

There is another return statement earlier in the ABCMeta.register method. The patch probably should also modify that.

Whoops, corrected that - should I add some more tests for that too?

You should, otherwise how would you prove it’s fixed? :)

Fair enough :)

-            return  # Already a subclass
+            return subclass # Already a subclass
PEP 8 advises to put two spaces before inline comments, for readability.
 (There is no need to upload a new patch, I’ll change that before commit.)

+        self.assertIsInstahce(c, (A,))
This is fixed in the newest version of your patch.  Running tests before
uploading diffs catches such errors :)

Yeah, I should've waited for the test to finish, but come on, "it was just a small change" :(

Now I know why you should always test everything at least, sorry about that :)

Committed to py3k as r88545.  You’ll notice that I fixed the nesting of the versionchanged directive and that I changed my mind about “returns”.  Thanks again!

In what use-cases would you want to call MyABC.register() when defining a class instead of inheriting from MyABC?

I always thought of the register() as hack to make it possible to support types written in C, which can't inherit from the ABC.

Someone may want to register with an ABC but not inherit methods or add a class to the mro.  It’s always been allowed by the register method; the new decorator feature is just a very minor nicety on top of that.

Edoardo, was your request motivated by a real use case where you didn’t want to inherit from the ABC?

Not really, but putting something in your inheritance lattice only to mark a class as providing an interface just doesn't seem right to me.

> In what use-cases would you want to call MyABC.register() when defining
> a class instead of inheriting from MyABC?

For example if you don't want to inherit a __dict__ for a tree-like data structure (see also issue11333).

Sounds good to me.  Thanks for the clarifications and satisfying my curiosity! :-)