1

I have used abc in the past, and I'd like to use them again, to enforce pure virtual like methods with @abstractmethod. This is in the context of a Python front-end to an API which users will extend frequently.

It's a bit too complicated for me to develop a reliably comprehensive test of scale, and I've always used abc as a black magic closed box, so I don't know where the cost of the abstraction and checks for abstracts is, and when it's likely incurred, or what the cost would actually be like or what it'd scale with.

I couldn't find satisfactorily complete information of the underlying mechanics anywhere, so any pointers to when and where the magic happens and at what cost would be immensely appreciated (Import? Instancing? Double dipping cost if the instance is extended?)

Some further info about the use case: Unlike in previous use cases (for me), where there was a very limit number of instances of each base object and abc measured to no perceivable overhead, this time around it would be for something (nodes in a DAG with a tree view) which can be instanced and then extended in place hundreds of times, and the number of virtual methods is likely to go up to somewhere around a dozen per class.

Inheritance is never multiple, and it's generally quite shallow, at the most two or three deep, the majority of the time just one.

Python 2.7 due to 3rd party platforms constraints.

1 Answers1

3

Prior to Python 2.6, using ABC came with some significant overhead. Issue 1762 reported this as a bug, and it was fixed for Python 2.6 (by moving some of the ABC machinery into the C implementation of object).

In newer versions of Python, there should be very little difference in performance between ABC-using and non-ABC using classes (the bug mentions a very small remaining difference in the speed of isinstance checks, but other actions having essentially zero difference in performance).

Blckknght
  • 100,903
  • 11
  • 120
  • 169
  • I had not thought of looking at issues; thanks, that's of great help. Would you know if the first validation of @abstractmethod happens at import time (or whenever the first dependencies are established), or is somewhat deferred? That is my assumption (on import), but it's an intuition at best. –  Jan 18 '16 at 06:01
  • 1
    Yes, almost all the work happens when the abstract class is defined. You can see the implementation of [`abc` module](https://hg.python.org/cpython/file/2.7/Lib/abc.py). What won't be obvious from the module's code is how it actually prevents the creation of objects with abstract methods. That's the bit that got moved into C code, in [`typeobject.c`](https://hg.python.org/cpython/file/2.7/Objects/typeobject.c). `type_set_abstractmethods` sets a flag if `__abstractmethods__` is assigned a non-empty list. Then, object_new` checks that flag before creating the new object. – Blckknght Jan 18 '16 at 06:49
  • That's all I needed to know. Might have a quick poke at the source as well if I have other doubts, I haven't looked at cpy source in dog ages. Thanks again. –  Jan 18 '16 at 06:55