Skip to content
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.

Sign up for GitHub

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

Jump to bottom

PEP 3121, 384 refactoring applied to dbm module #59855

Closed
RobinSchreiber mannequin opened this issue Aug 14, 2012 · 7 comments
Closed

PEP 3121, 384 refactoring applied to dbm module #59855

RobinSchreiber mannequin opened this issue Aug 14, 2012 · 7 comments
Labels
extension-modules C modules in the Modules dir

Comments

@RobinSchreiber
Copy link
Mannequin

RobinSchreiber mannequin commented Aug 14, 2012

BPO 15650
Nosy @loewis, @vstinner, @asvetlov
Superseder
  • bpo-1635741: Py_Finalize() doesn't clear all Python objects at exit
    		•
    Files
  • _dbmmodule_pep3121-384_v0.patch
  • Issue15650_v2.diff
    		•

    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 = None
closed_at = <Date 2020-12-18.00:43:53.569>
created_at = <Date 2012-08-14.18:14:33.875>
labels = ['extension-modules']
title = 'PEP 3121, 384 refactoring applied to dbm module'
updated_at = <Date 2020-12-18.00:43:53.568>
user = 'https://bugs.python.org/RobinSchreiber'

    bugs.python.org fields:

    activity = <Date 2020-12-18.00:43:53.568>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2020-12-18.00:43:53.569>
closer = 'vstinner'
components = ['Extension Modules']
creation = <Date 2012-08-14.18:14:33.875>
creator = 'Robin.Schreiber'
dependencies = []
files = ['26804', '27774']
hgrepos = []
issue_num = 15650
keywords = ['pep3121']
message_count = 7.0
messages = ['168216', '172310', '172320', '172323', '172644', '176650', '383279']
nosy_count = 4.0
nosy_names = ['loewis', 'vstinner', 'asvetlov', 'Robin.Schreiber']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '1635741'
type = None
url = 'https://bugs.python.org/issue15650'
versions = ['Python 3.4']
    @RobinSchreiber
    Copy link
    Mannequin Author

    RobinSchreiber mannequin commented Aug 14, 2012

    Changes proposed in PEP-3121 and PEP-384 have now been applied to the dbm module!

    @RobinSchreiber RobinSchreiber mannequin added the extension-modules C modules in the Modules dir label Aug 14, 2012
    @asvetlov
    Copy link
    Contributor

    asvetlov commented Oct 7, 2012

    Robin, why do you increment refcounter for type object on every construction of dbm instance?

    Also I would to see macros in uppercase if possible.

    @RobinSchreiber
    Copy link
    Mannequin Author

    RobinSchreiber mannequin commented Oct 7, 2012

    PEP-384 demands, among other things, that the TypeObjects themselves are transformed to Heaptypes. This means that the Typeobjects, that are created from this new stable ABI, reside within the heap and therefore have to be managed by the Python GC. This is of course done by appropriately incref- and decrefing of the specific Heaptype.

    @asvetlov
    Copy link
    Contributor

    asvetlov commented Oct 7, 2012

    From my perspective type object is referenced by module state.
    While module is present it's state hold all types exposed by module.
    After module has deleted it's state has cleaned up and types has gone away — thats look good to me.

    Instances of python classes (not extensions) hold ownership for it's class. I guess it done because python class can be constructed inside function and instance of this class should work after exit from that function like closure does.

    In case of extension modules enough to hold type reference into module state itself.

    Thoughts?

    @asvetlov
    Copy link
    Contributor

    Robin, after thinking I would to agree with your decision to hold reference to type into type instance.

    Please, can you describe your check like:

    if((void *)type->tp_dealloc == (void *)dbm_dealloc) {
    Py_DECREF(type);
}

    Why you decref only if type->tp_dealloc points to module's dealloc? What are you protected from? What other values also possible?

    @RobinSchreiber
    Copy link
    Mannequin Author

    RobinSchreiber mannequin commented Nov 29, 2012

    Take a look at the discussion in bpo-15653.

    @vstinner
    Copy link
    Member

    Fixed by:

    commit bf69a8f
    Author: Dong-hee Na <donghee.na92@gmail.com>
    Date: Tue Jun 16 01:20:54 2020 +0900

    bpo-1635741: Port _dbm module to multiphase initialization (GH-20848)

    @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
    Assignees
    No one assigned
    Labels
    extension-modules C modules in the Modules dir
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    2 participants
    @vstinner @asvetlov