classification
Title: Implementation of @abstractmethod for PEP 3119
Type: Stage:
Components: Interpreter Core Versions: Python 3.0
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gvanrossum, nnorwitz
Priority: normal Keywords: patch

Created on 2007-04-24 22:45 by gvanrossum, last changed 2008-01-06 22:29 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
abstract.diff gvanrossum, 2007-04-24 22:45 Initial version of the patch
abstract.diff gvanrossum, 2007-04-24 23:31 Version 2 (C89 syntax, fixed leak)
abstract.diff gvanrossum, 2007-04-25 16:51 Version 2 (Neal's nits+refactoring, optimization)
Messages (5)
msg52521 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-04-24 22:45
This implements a new builtin, abstractmethod, which when used as a method decorator declares the method to be abstract, causing the class to be abstract (i.e. it cannot be instantiated).  A subclass of an abstract class is still abstract unless it overrides all abstract base methods.
msg52522 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-04-24 23:31
Here's a version that compiles with C89 (GCC 2.96) and doesn't leak the 'fast' object.
File Added: abstract.diff
msg52523 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2007-04-25 05:35
Perhaps this is a better question for the PEP rather than the impl, but can attributes be abstract?

class Foo:
  abstract_override_me = ???

If so, then __isabstractmethod__ might be better named as:  __isabstract__.  I think this might work:

class Abstract:
  __isabstractmethod__ = True

class Foo:
  abstract_override_me = Abstract()

Do you want arbitrary objects to be able to declare their abstractness or should the impl also check that an attribute is callable?

check_new_abstracts() should return a Py_ssize_t since it returns the size of a container (set).  The return value is already captured in a Py_ssize_t, so it's just the signature (and prototype) that should change.

PySet_Add()s return value isn't checked in check_new_abstracts().  It might be nice to factor out the common code between the two new functions into a static helper function.  That would get rid of the PySet_Add problem.

By calling: PyObject_GetAttrString(meth, "__isabstractmethod__"), that means a new string object is allocated and then thrown away with each call.  This could be improved by creating an interned string for "__isabstractmethod__".  (I realize this is only when types are created which shouldn't be too often.)
msg52524 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-04-25 16:51
Neil: The intention is that only methods can be abstract.  I don't think we should attempt to only check the __isabstractmethod__ attribute for objects that we know are methods; that would be an expensive check to make (you'd have to call __get__ if it exists) and since this is a __magic__ attribute, you void your warrantee if you mess with it. :-)

In this version (v3), I've fixed the C nits and done the refactoring you suggested, and also added an optimization: check_abstracts() returns immediately if the base class doesn't have the ABSTRACT flag set.
File Added: abstract.diff
msg52525 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-07-11 13:08
Something like this was submitted quite a while ago.
History
Date User Action Args
2008-01-06 22:29:46adminsetkeywords: - py3k
versions: + Python 3.0
2007-04-24 22:45:36gvanrossumcreate