Skip to content

Implementation of @abstractmethod for PEP 3119 #44895

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gvanrossum opened this issue Apr 24, 2007 · 5 comments
Closed

Implementation of @abstractmethod for PEP 3119 #44895

gvanrossum opened this issue Apr 24, 2007 · 5 comments
Assignees
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@gvanrossum
Copy link
Member

BPO 1706989
Nosy @gvanrossum
Files
  • abstract.diff: Initial version of the patch
  • abstract.diff: Version 2 (C89 syntax, fixed leak)
  • abstract.diff: Version 2 (Neal's nits+refactoring, optimization)
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/gvanrossum'
    closed_at = <Date 2008-01-06.22:29:46.104>
    created_at = <Date 2007-04-24.22:45:36.000>
    labels = ['interpreter-core']
    title = 'Implementation of @abstractmethod for PEP 3119'
    updated_at = <Date 2008-01-06.22:29:46.104>
    user = 'https://github.com/gvanrossum'

    bugs.python.org fields:

    activity = <Date 2008-01-06.22:29:46.104>
    actor = 'admin'
    assignee = 'gvanrossum'
    closed = True
    closed_date = None
    closer = None
    components = ['Interpreter Core']
    creation = <Date 2007-04-24.22:45:36.000>
    creator = 'gvanrossum'
    dependencies = []
    files = ['7966', '7967', '7968']
    hgrepos = []
    issue_num = 1706989
    keywords = ['patch']
    message_count = 5.0
    messages = ['52521', '52522', '52523', '52524', '52525']
    nosy_count = 2.0
    nosy_names = ['gvanrossum', 'nnorwitz']
    pr_nums = []
    priority = 'normal'
    resolution = 'accepted'
    stage = None
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue1706989'
    versions = ['Python 3.0']

    @gvanrossum
    Copy link
    Member Author

    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.

    @gvanrossum gvanrossum self-assigned this Apr 24, 2007
    @gvanrossum gvanrossum added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Apr 24, 2007
    @gvanrossum gvanrossum self-assigned this Apr 24, 2007
    @gvanrossum gvanrossum added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Apr 24, 2007
    @gvanrossum
    Copy link
    Member Author

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

    @nnorwitz
    Copy link
    Mannequin

    nnorwitz mannequin commented Apr 25, 2007

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

    @gvanrossum
    Copy link
    Member Author

    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

    @gvanrossum
    Copy link
    Member Author

    Something like this was submitted quite a while ago.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs)
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant