This makes me a little sad. So, a few observations: - The use of metaclasses for (almost?) every feature in this library makes it prone to metaclass conflicts.

This makes me a little sad. So, a few observations: - The use of metaclasses for (almost?) every feature in this library makes it prone to metaclass conflicts. What if I want to inherit from two classes that use two different features from the library? >>> class MetaOne(type): ... pass ... >>> class MetaTwo(type): ... pass ... >>> class One(metaclass=MetaOne): ... pass ... >>> class Two(metaclass=MetaTwo): ... pass ... >>> class Both(One, Two): ... pass ... Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases - I've never had a problem with other programmers accidentally changing my "constants" (eg. THE_THINGS_IN_ALL_CAPS) and I've never had a problem with other programmers accidentally changing my "private" attributes (eg. _prepended_with_underscore). Naming conventions are good enough for those purposes, in my experience. - And when they're not, there's __name_mangling, which is sufficient to avoid the need for a 'final'. Compilers can make use of 'final', which is why final exists in Cython. I'm not sure the purpose in pure Python. - There's no need for the distinction between an Abstract class and and Interface. Python already supports multiple inheritance of abstract classes.