[Python-3000] adding @abstractmethods after class creation

Steven Bethard steven.bethard at gmail.com
Wed Apr 25 04:29:20 CEST 2007

On 4/24/07, guido.van.rossum <python-checkins at python.org> wrote:
> +We define a new built-in decorator, ``@abstractmethod``
> +**Implementation:** The ``@abstractmethod`` decorator sets the
> +function attribute ``__isabstractmethod__`` to the value ``True``.
> +The ``type.__new__`` method computes the type attribute
> +``__abstractmethods__`` as the set of all method names that have an
> +``__isabstractmethod__`` attribute whose value is true.  It does this
> +by combining the ``__abstractmethods__` attributes of the base
> +classes, adding the names of all methods in the new class dict that
> +have a true ``__isabstractmethod__`` attribute, and removing the names
> +of all methods in the new class dict that don't have a true
> +``__isabstractmethod__`` attribute.  If the resulting
> +``__abstractmethods__`` set is non-empty, the class is considered
> +abstract, and attempts to instantiate it will raise ``TypeError``.

(Hope this wasn't covered in that really long thread. I couldn't see
an answer in the PEP.)

So what happens in a situation like::

    class C:
    C.foo = abstractmethod(foo)

It seems from the description above like ``C.__abstractmethods__``
would be empty, and therefore C could be instantiated even though it
has an abstract method.

I don't mind at all if we just say "don't do that", but then
@abstractmethod should probably be documented explicitly as only being
usable within a class body.  (Note that this is different from
@classmethod and @staticmethod which can be used after the fact.)

I guess the other option would be to have __setattr__ on classes
append to the __abstractmethods__ list when passed a value with
__isabstractmethod__ == True. But this would probably make setting
attributes on classes (though not on other objects) slower.

I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

More information about the Python-3000 mailing list