This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: PEP 3121, 384 refactoring applied to dbm module
Type: Stage: resolved
Components: Extension Modules Versions: Python 3.4
Status: closed Resolution: duplicate
Dependencies: Superseder: Py_Finalize() doesn't clear all Python objects at exit
View: 1635741
Assigned To: Nosy List: Robin.Schreiber, asvetlov, loewis, vstinner
Priority: normal Keywords: pep3121

Created on 2012-08-14 18:14 by Robin.Schreiber, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
_dbmmodule_pep3121-384_v0.patch Robin.Schreiber, 2012-08-14 18:14
Issue15650_v2.diff asvetlov, 2012-10-29 09:36 review
Messages (7)
msg168216 - (view) Author: Robin Schreiber (Robin.Schreiber) * (Python triager) Date: 2012-08-14 18:14
Changes proposed in PEP3121 and PEP384 have now been applied to the dbm module!
msg172310 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-10-07 15:36
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.
msg172320 - (view) Author: Robin Schreiber (Robin.Schreiber) * (Python triager) Date: 2012-10-07 16:47
PEP384 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.
msg172323 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-10-07 17:08
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.

msg172644 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-10-11 14:04
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) {

Why you decref only if type->tp_dealloc points to module's dealloc? What are you protected from? What other values also possible?
msg176650 - (view) Author: Robin Schreiber (Robin.Schreiber) * (Python triager) Date: 2012-11-29 13:43
Take a look at the discussion in Issue 15653.
msg383279 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-12-18 00:43
Fixed by:

commit bf69a8f99f1b0e19a59509c6c4d7015a31d881a1
Author: Dong-hee Na <>
Date:   Tue Jun 16 01:20:54 2020 +0900

    bpo-1635741: Port _dbm module to multiphase initialization (GH-20848)
Date User Action Args
2022-04-11 14:57:34adminsetgithub: 59855
2020-12-18 00:43:53vstinnersetstatus: open -> closed

superseder: Py_Finalize() doesn't clear all Python objects at exit

nosy: + vstinner
messages: + msg383279
resolution: duplicate
stage: resolved
2012-11-29 13:43:33Robin.Schreibersetmessages: + msg176650
2012-11-08 13:19:26Robin.Schreibersetkeywords: + pep3121, - patch
2012-10-29 09:36:54asvetlovsetfiles: + Issue15650_v2.diff
2012-10-11 14:04:11asvetlovsetmessages: + msg172644
2012-10-07 18:20:34pitrousetnosy: + loewis
2012-10-07 17:08:59asvetlovsetmessages: + msg172323
2012-10-07 16:47:07Robin.Schreibersetmessages: + msg172320
2012-10-07 15:36:15asvetlovsetmessages: + msg172310
2012-08-27 03:40:58belopolskylinkissue15787 dependencies
2012-08-17 16:36:40asvetlovsetnosy: + asvetlov
2012-08-14 18:14:33Robin.Schreibercreate