[Patches] [ python-Patches-1706989 ] Implementation of @abstractmethod for PEP 3119

[SourceForge.net]

Patches item #1706989, was opened at 2007-04-24 18:45
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1706989&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Implementation of @abstractmethod for PEP 3119

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-25 12:51

Message:
Logged In: YES 
user_id=6380
Originator: YES

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

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-25 01:35

Message:
Logged In: YES 
user_id=33168
Originator: NO

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.)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-04-24 19:31

Message:
Logged In: YES 
user_id=6380
Originator: YES

Here's a version that compiles with C89 (GCC 2.96) and doesn't leak the
'fast' object.
File Added: abstract.diff

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1706989&group_id=5470