GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||
GeezerVison is showing github.com — bpo-42972: Fully implement GC protocol for re types by erlend-aasland · Pull Request #26368 · python/cpython Conversation
|
| break; | ||
| } | ||
| } | ||
| PyObject_GC_Track(self); |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
@pablogsal I'm unsure if this it the correct place to start tracking the newly created pattern object. My reasoning was that AFAICS, it seems to be fully initialised here, unless I've missed something.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
IMO it's the right place.
It must be called before the first DECREF(self), otherwise PyObject_GC_UnTrack() crash in dealloc.
Usually, it's better to only track an object once it's fully initialized, but here it's more convient to do it here to be able to simply call DECREF() on error. The bare minimum is that traverse must be crash when an object started to be tracked. I added a test in debug mode for that: see traverse(visit_validate) in PyObject_GC_Track().
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that calling PyObject_ClearWeakRefs() in a clear function is safe. What do you think?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| break; | ||
| } | ||
| } | ||
| PyObject_GC_Track(self); |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
IMO it's the right place.
It must be called before the first DECREF(self), otherwise PyObject_GC_UnTrack() crash in dealloc.
Usually, it's better to only track an object once it's fully initialized, but here it's more convient to do it here to be able to simply call DECREF() on error. The bare minimum is that traverse must be crash when an object started to be tracked. I added a test in debug mode for that: see traverse(visit_validate) in PyObject_GC_Track().
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
… refs in tp_clear
|
Thanks @erlend-aasland for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.10. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
GH-26411 is a backport of this pull request to the 3.10 branch. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
(cherry picked from commit fba42d1) Co-authored-by: Erlend Egeberg Aasland <[email protected]>
|
Thanks @erlend-aasland for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.10. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
(cherry picked from commit fba42d1) Co-authored-by: Erlend Egeberg Aasland <[email protected]>
|
GH-26414 is a backport of this pull request to the 3.10 branch. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
) (cherry picked from commit fba42d1) Co-authored-by: Erlend Egeberg Aasland <[email protected]>
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.