[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Changes by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 -Python 2.7, Python 3.5, Python 3.6 ___ Python tracker

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Raymond Hettinger added the comment: New changeset 8110dbd470f3daa4de58dda66d360e3c26d3b94f by Raymond Hettinger in branch 'master': bpo-26491 Defer DECREFs until enumobject is in a consistent state (#3747) https://github.com/python/cpython/commit/8110dbd470f3daa4de58dda66d360e3c26d3b94f

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Changes by Raymond Hettinger : -- pull_requests: +3734 ___ Python tracker ___

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Changes by Raymond Hettinger : -- status: pending -> open ___ Python tracker ___

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Changes by Serhiy Storchaka : -- status: open -> pending ___ Python tracker ___

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Changes by Serhiy Storchaka : -- assignee: -> rhettinger status: pending -> open ___ Python tracker ___

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Changes by Serhiy Storchaka : -- status: open -> pending ___ Python tracker ___

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Serhiy Storchaka added the comment: This change is not broken. It is just redundant. If you are still inclined to apply this changes, I would suggest to factor out common code in enum_next_long and enum_next. > Oh, this change was not intended. I don't know how it occurred. Any reply changes

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Raymond Hettinger added the comment: Deferring decrefs as late as possible is a good practice, reducing the risk of bugs being introduced later. There have been other places where there were bugs that arose due to premature decreffing. I wrote the original code for enumerate, am the primary

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

STINNER Victor added the comment: > status: pending -> open Oh, this change was not intended. I don't know how it occurred. -- status: open -> pending ___ Python tracker

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

STINNER Victor added the comment: Raymond: Do you have an example to trigger the issue? -- nosy: +haypo status: pending -> open ___ Python tracker ___

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Changes by Serhiy Storchaka : -- status: open -> pending ___ Python tracker ___ ___

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Changes by Serhiy Storchaka : -- assignee: serhiy.storchaka -> ___ Python tracker ___

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

New submission from Serhiy Storchaka: I don't see possible bug here. The first item of the tuple is always int or None. It's decrefing don't trigger executing user code. The second item of the tuple is decrefed when the refcount of the tuple is 2 and we own all references. The code triggered

[issue26491] Defer DECREFs until enum object is in a consistent state for re-entrancy

Changes by Raymond Hettinger : -- assignee: serhiy.storchaka components: Interpreter Core files: enumerate_defer_decref.diff keywords: patch nosy: rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Defer