[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``
[snip]
> +**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:
pass
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.
STeVe
--
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