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.

Author eelizondo
Recipients eelizondo, petr.viktorin, scoder, vstinner
Date 2019-02-12.20:38:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1550003920.96.0.642847264739.issue35810@roundup.psfhosted.org>
In-reply-to
Content
Thanks for the thorough feedback Stefan!

I would like to just add an extra thing to everything you already mentioned: 

This change will NEVER cause a crash. The change that we are introducing is an incref to a type object (no decrefs). Thus, there are two-ish scenarios:

1) The type object is immortal: This means that the type does not incref/decref its refcount automatically on instance creation. Adding this incref will not affect the fact that it's already immortal. An example of this is structsequences. The change that I added in the PR is to convert it to an refcounted type (instead of immortal).

2.1) The type is recounted (automatically): Achieved through the generic allocation which already increfs the type. Given that this refactors that incref, then this behavior should stay exactly the same.

2.2) The type is refcounted (manually): Achieved by not using the generic allocation and instead using `PyObject_{,GC}_New{Var}`. To properly refcount this type, a manual incref is required after object instantiation. Usually, I've seen this pattern in very carefully engineered types where a NULL is jammed into `tp_new` to make it into a non-instantiable type. Examples of this are Modules/_tkinter.c and Modules/_curses_panel.c. Anyways, adding this incref will leak this type, but will not cause a crash.
History
Date User Action Args
2019-02-12 20:38:41eelizondosetrecipients: + eelizondo, scoder, vstinner, petr.viktorin
2019-02-12 20:38:40eelizondosetmessageid: <1550003920.96.0.642847264739.issue35810@roundup.psfhosted.org>
2019-02-12 20:38:40eelizondolinkissue35810 messages
2019-02-12 20:38:40eelizondocreate