[issue42482] TracebackException should not hold reference to the exception traceback

Guido van Rossum added the comment: For background, see https://github.com/iritkatriel/cpython/pull/3#issuecomment-734640036 -- it seems the link to exc_traceback was added with little concern for the original design of TracebackExceptionGroup. The question is, can we get rid of it, even

[issue42482] TracebackException should not hold reference to the exception traceback

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42482] TracebackException should not hold reference to the exception traceback

Irit Katriel added the comment: >From the TracebackException docstring: "The traceback module captures enough attributes from the original exception to this intermediary form to ensure that no references are held, while still being able to fully print or format it." > If the tracebacks are

[issue42482] TracebackException should not hold reference to the exception traceback

Steven D'Aprano added the comment: This would be a change of behaviour, and 3.8 and 3.9 are in feature freeze, so we could only add it in 3.10. You say: "it's supposed to capture the output without holding references to real things" Is this requirement documented somewhere, or is it just

[issue42482] TracebackException should not hold reference to the exception traceback

Change by Irit Katriel : -- keywords: +patch pull_requests: +22413 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23531 ___ Python tracker ___

[issue42482] TracebackException should not hold reference to the exception traceback

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42482] TracebackException should not hold reference to the exception traceback

Change by Irit Katriel : -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42482] TracebackException should not hold reference to the exception traceback

New submission from Irit Katriel : TracebackException holds a reference to the exc_traceback, which is wrong because (1) it's supposed to capture the output without holding references to real things. (2) it makes comparison wrong for equivalent exceptions, as in this example

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Inada Naoki added the comment: New changeset c8aaf71dde464c0c351e2f935f87652c3d54 by Volker-Weissmann in branch 'master': bpo-17852: Doc: Fix the tutorial about closing files (GH-23135) https://github.com/python/cpython/commit/c8aaf71dde464c0c351e2f935f87652c3d54 -- nosy:

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Volker Weißmann added the comment: The PR below fixed it: https://github.com/python/cpython/pull/23135 -- ___ Python tracker ___

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

miss-islington added the comment: New changeset 01fcde89d7d56321078be1739e759fece61d0a2b by Miss Islington (bot) in branch '3.8': bpo-17852: Doc: Fix the tutorial about closing files (GH-23135) https://github.com/python/cpython/commit/01fcde89d7d56321078be1739e759fece61d0a2b --

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Change by miss-islington : -- pull_requests: +22410 pull_request: https://github.com/python/cpython/pull/23528 ___ Python tracker ___

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Change by miss-islington : -- nosy: +miss-islington nosy_count: 13.0 -> 14.0 pull_requests: +22409 pull_request: https://github.com/python/cpython/pull/23527 ___ Python tracker

[issue42465] Reference to subclass method resolve() in PurePath docs

s a filesystem." https://docs.python.org/3.7/library/pathlib.html#pure-paths -- assignee: docs@python components: Documentation messages: 381848 nosy: docs@python, john.engelke priority: normal severity: normal status: open title: Reference to subclass method resolve() in PurePath docs v

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Change by Nikolaus Rath : -- nosy: -nikratio ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Change by Charles-François Natali : -- nosy: -neologix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42348] Language Reference: Set items

Terry J. Reedy added the comment: Raymond's last point is that set objects should be immutably hashable. I would say 'must be' in the sense that mutably hashable objects break sets in various ways, starting with uniqueness. If we were to make a change, I think the replacement should be

[issue42348] Language Reference: Set items

Raymond Hettinger added the comment: I recommend leaving the text as is, and possibly creating a new FAQ entry discussing the relationship between immutability and hashability (something that I consider to be an intermediate or advanced topic). Other thought: * The set discussion should

[issue42348] Language Reference: Set items

Yash Shete added the comment: Should it be "These represents hashable objects" -- nosy: +Pixmew ___ Python tracker ___ ___

[issue42348] Language Reference: Set items

New submission from Batuhan Taskaya : The data types section of the language reference (https://docs.python.org/3.10/reference/datamodel.html#the-standard-type-hierarchy) has this description directly under the Set type (which has 2 childs, set and frozenset). > These represent unorde

[issue42348] Language Reference: Set items

Change by Batuhan Taskaya : -- assignee: -> docs@python components: +Documentation nosy: +docs@python, rhettinger ___ Python tracker ___

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Change by Jakub Stasiak : -- nosy: +jstasiak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32426] Tkinter: reference document of possible cursor names

latform cursors are illustrated at https://tkdocs.com/shipman/cursors.html. The cursor hot spot, the point reported for mouse clicks, depends on the cursor. """ I may try to reference this, rather than copy it, in the ttk doc. -- assignee: -> docs@python components:

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

Serhiy Storchaka added the comment: PyModule_AddObject() has unique weird design, it is easy to misuse, and most code misuse it, but fixing it would break the code which uses it correctly. I did not see any problems with PyTuple_GetItem(). -- ___

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

STINNER Victor added the comment: > If you want to work only with non-borrowed references, (...) This is not my goal here. My goal is to reduce the risk of memory leaks. -- ___ Python tracker

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

STINNER Victor added the comment: In bpo-1635741, I added PyModule_AddObjectRef() (commit 8021875bbcf7385e651def51bc597472a569042c): https://docs.python.org/dev/c-api/module.html#c.PyModule_AddObjectRef "Similar to PyModule_AddObject() but don't steal a reference to the value on su

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

STINNER Victor added the comment: New changeset 78ba7c69ada2f7eefd4e3ea375337d78dc2ce721 by kj in branch 'master': bpo-42294: Grammar fixes in doc glossary strong/weak refs (GH-23227) https://github.com/python/cpython/commit/78ba7c69ada2f7eefd4e3ea375337d78dc2ce721 --

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

Change by Ken Jin : -- nosy: +kj nosy_count: 5.0 -> 6.0 pull_requests: +22130 pull_request: https://github.com/python/cpython/pull/23227 ___ Python tracker ___

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

Serhiy Storchaka added the comment: I concur with Mark. If you want to work only with non-borrowed references, use PySequence_GetItem() and PySequence_SetItem(). It has a cost: it is slower and needs checking errors. If you need more performant solution and binary compatibility across

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

STINNER Victor added the comment: > PyTuple_SetItem() does clear the previous item, it uses Py_XSETREF. The macro > version (PyTuple_SET_ITEM) does not clear the previous item. Oh sorry, I was thinking at PyTuple_SET_ITEM(). -- ___ Python tracker

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

Change by hai shi : -- nosy: +shihai1991 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

Ronald Oussoren added the comment: PyTuple_SetItem() does clear the previous item, it uses Py_XSETREF. The macro version (PyTuple_SET_ITEM) does not clear the previous item. -- nosy: +ronaldoussoren ___ Python tracker

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

atic inline functions in the limited C API. If it's an issue, we can consider to only do that in Include/cpython/object.h. > There seems to be some confusion about borrowed references and stolen > references in > https://pythoncapi.readthedocs.io/bad_api.html#borrowed-references "

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

://pythoncapi.readthedocs.io/bad_api.html#borrowed-references "Stealing" a reference is perfectly safe. Returning a "borrowed" reference is not. So, don't bother with `PyTuple_SetItemRef()`, as `PyTupleSetItem()` is safe. -- nosy: +Mark.Shannon __

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

Change by STINNER Victor : -- pull_requests: +22107 pull_request: https://github.com/python/cpython/pull/23209 ___ Python tracker ___

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

Change by STINNER Victor : -- pull_requests: +22105 pull_request: https://github.com/python/cpython/pull/23207 ___ Python tracker ___

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

STINNER Victor added the comment: New changeset 23c5f93b83f78f295313e137011edb18b24c37c2 by Victor Stinner in branch 'master': bpo-42294: Add borrowed/strong reference to doc glossary (GH-23206) https://github.com/python/cpython/commit/23c5f93b83f78f295313e137011edb18b24c37c2

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

Change by STINNER Victor : -- keywords: +patch pull_requests: +22104 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23206 ___ Python tracker ___

[issue42294] [C API] Add new C functions with more regular reference counting like PyTuple_GetItemRef()

New submission from STINNER Victor : The C API of Python uses and abuses borrowed references and stealing references for performance. When such function is used in some very specific code for best performances, problems arise when they are the only way to access objects. Reference counting

[issue25769] Crash due to using weakref referent without acquiring a strong reference

Change by Irit Katriel : -- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker ___

[issue42262] [C API] Add Py_NewRef() function to get a new strong reference to an object

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue42262] [C API] Add Py_NewRef() function to get a new strong reference to an object

STINNER Victor added the comment: New changeset 53a03aafd5812018a3821a2e83063fd3d6cd2576 by Victor Stinner in branch 'master': bpo-42262: Add Py_NewRef() and Py_XNewRef() (GH-23152) https://github.com/python/cpython/commit/53a03aafd5812018a3821a2e83063fd3d6cd2576 --

[issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

Jason R. Coombs added the comment: I marked bpo-42263 as a duplicate of this issue. This issue is implicated in preventing the desired fix for bpo-37193, where a thread wishes to remove the handle to itself after performing its duty. By removing its own handle, it can never be joined, and

[issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

Change by Jason R. Coombs : -- versions: +Python 3.10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42263] Removing thread reference in thread results in leaked reference

2 (threading._shutdown() race condition) causes reference leak ___ Python tracker <https://bugs.python.org/issue42263> ___ ___ Python-bugs-list mailing list U

[issue42263] Removing thread reference in thread results in leaked reference

Martin Panter added the comment: Maybe this is related to (or duplicate of) Issue 37788? Python 3.7 has a regression where threads that are never joined cause leaks; previous code was written assuming you didn't need to join threads. Do you still see the leak even if you don't clear the

[issue42263] Removing thread reference in thread results in leaked reference

Change by Martin Panter : -- nosy: +martin.panter ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42263] Removing thread reference in thread results in leaked reference

reference leaks. If you join the thread in the test, the leak is not detected. However, I believe that's because, in order to join on the thread, you must also hold a handle to the thread, so the condition isn't triggered. -- ___ Python tracker <ht

[issue42263] Removing thread reference in thread results in leaked reference

Ronald Oussoren added the comment: Could this be a race condition? The thread that's created in the test is not waited on (join), it may or may not have exited by the time the test function returns. -- nosy: +ronaldoussoren ___ Python tracker

[issue42263] Removing thread reference in thread results in leaked reference

New submission from Jason R. Coombs : In issue37193, I'd worked on an implementation in which a thread reference would be removed as the thread was closing, but this led to a memory leak caught by the buildbots (https://bugs.python.org/issue37193#msg380172). As I tracked down the issue in GH

[issue42262] [C API] Add Py_NewRef() function to get a new strong reference to an object

Change by Erlend Egeberg Aasland : -- nosy: +erlendaasland ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42262] [C API] Add Py_NewRef() function to get a new strong reference to an object

Change by Simon Cross : -- nosy: +hodgestar ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42262] [C API] Add Py_NewRef() function to get a new strong reference to an object

STINNER Victor added the comment: > The problem in these patterns is that the object has to be written twice. I'm talking about the variable name which has to be repeated (written twice) in the source code. -- ___ Python tracker

[issue42262] [C API] Add Py_NewRef() function to get a new strong reference to an object

Change by STINNER Victor : -- keywords: +patch pull_requests: +22064 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23152 ___ Python tracker ___

[issue42262] [C API] Add Py_NewRef() function to get a new strong reference to an object

New submission from STINNER Victor : In C, the following pattern (A) is very common: Py_INCREF(sysdict); interp->sysdict = sysdict; * (1) Increment the reference counter * (2) Store a reference to the object somewhere Similar pattern (B) using return: Py_INCREF(temp); ret

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Change by Volker Weißmann : -- nosy: +Volker Weißmann nosy_count: 12.0 -> 13.0 pull_requests: +22049 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23135 ___ Python tracker

[issue40255] Fixing Copy on Writes from reference counting

Inada Naoki added the comment: >> Fast shutdown option > > You can use os._exit(0). Yes. Instagram use it as `atexit.register(os._exit, 0)`. https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172 I think this hack can be supported in multiprocessing

[issue40255] Fixing Copy on Writes from reference counting

STINNER Victor added the comment: > Fast shutdown option You can use os._exit(0). -- ___ Python tracker ___ ___ Python-bugs-list

[issue42099] Fix reference to ob_type in unionobject.c and ceval

Mark Shannon added the comment: Thanks Neil -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue42099] Fix reference to ob_type in unionobject.c and ceval

Mark Shannon added the comment: New changeset 0564aafb71a153dd0aca4b9266dfae9336a4f2cb by Neil Schemenauer in branch 'master': bpo-42099: Fix reference to ob_type in unionobject.c and ceval (GH-22829) https://github.com/python/cpython/commit/0564aafb71a153dd0aca4b9266dfae9336a4f2cb

[issue40255] Fixing Copy on Writes from reference counting

Change by Inada Naoki : -- versions: +Python 3.10 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40255] Fixing Copy on Writes from reference counting

Inada Naoki added the comment: I'm big -1 too. But I am interested in Instagram usage. * How % of heap are CoW-ed with gc.freeze()? * When CoW happen? in execution time, or shutdown? * Which type cause CoW? I have two ideas to reduce CoW: * Fast shutdown option Currently Python try to

[issue41911] Language reference for expressions incorrectly specifies what type of object(s) are expected

Brett Cannon added the comment: It turns out the "expressions" page of the language reference makes multiple claims about types which do not hold, e.g. for multiplication, "The arguments must either both be numbers, or one argument must be an integer and the other mus

[issue42099] Fix reference to ob_type in unionobject.c and ceval

Change by Neil Schemenauer : -- keywords: +patch pull_requests: +21784 pull_request: https://github.com/python/cpython/pull/22829 ___ Python tracker ___

[issue42099] Fix reference to ob_type in unionobject.c and ceval

that renames the ob_type member would work. I'll make a separate bug for that. -- assignee: vstinner components: Interpreter Core messages: 379155 nosy: nascheme, vstinner priority: normal severity: normal stage: patch review status: open title: Fix reference to ob_type in unionobject.c

[issue35414] A reference counting bug in PyState_RemoveModule()

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue36179] _hashopenssl has reference leaks in OOM case

Change by Gregory P. Smith : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue36179] _hashopenssl has reference leaks in OOM case

Irit Katriel added the comment: Can this be closed? -- nosy: +iritkatriel ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35414] A reference counting bug in PyState_RemoveModule()

Irit Katriel added the comment: Can this be closed? -- nosy: +iritkatriel ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue41984] Empty __slots__ can create untracked reference cycles

Brandt Bucher added the comment: New changeset aeb66c1abbf4ec214e2e80eb972546996d1a1571 by Miss Skeleton (bot) in branch '3.8': bpo-41984: GC track all user classes (GH-22701/GH-22707) https://github.com/python/cpython/commit/aeb66c1abbf4ec214e2e80eb972546996d1a1571 --

[issue41984] Empty __slots__ can create untracked reference cycles

Change by miss-islington : -- pull_requests: +21676 pull_request: https://github.com/python/cpython/pull/22707 ___ Python tracker ___

[issue41984] Empty __slots__ can create untracked reference cycles

Brandt Bucher added the comment: New changeset d197b2bb3e401bed53987b65a7ceb6c712c4f5bd by Miss Skeleton (bot) in branch '3.9': bpo-41984: GC track all user classes (GH-22701/GH-22702) https://github.com/python/cpython/commit/d197b2bb3e401bed53987b65a7ceb6c712c4f5bd --

[issue41984] Empty __slots__ can create untracked reference cycles

Change by Brandt Bucher : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue41984] Empty __slots__ can create untracked reference cycles

Brandt Bucher added the comment: New changeset c13b847a6f913b72eeb71651ff626390b738d973 by Brandt Bucher in branch 'master': bpo-41984: GC track all user classes (GH-22701) https://github.com/python/cpython/commit/c13b847a6f913b72eeb71651ff626390b738d973 --

[issue41984] Empty __slots__ can create untracked reference cycles

Change by miss-islington : -- pull_requests: +21673 pull_request: https://github.com/python/cpython/pull/22703 ___ Python tracker ___

[issue41984] Empty __slots__ can create untracked reference cycles

Change by miss-islington : -- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +21672 pull_request: https://github.com/python/cpython/pull/22702 ___ Python tracker

[issue41984] Empty __slots__ can create untracked reference cycles

Change by Brandt Bucher : -- keywords: +patch pull_requests: +21671 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22701 ___ Python tracker ___

[issue41984] Empty __slots__ can create untracked reference cycles

Brandt Bucher added the comment: Actually, never mind. Because of the way finalization works, we need to create untracked *types* for these tests, not untracked *instances*. PR up soon. -- ___ Python tracker

[issue41984] Empty __slots__ can create untracked reference cycles

Brandt Bucher added the comment: I'll hold off until https://bugs.python.org/issue42039 is resolved. -- ___ Python tracker ___ ___

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: In any case, you can expose: https://docs.python.org/3/c-api/gcsupport.html#c.PyObject_GC_UnTrack in the testcapi module -- ___ Python tracker

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: > I'm not sure that's true... :) Oh boy, I need toehemyeah I will be back inone second... -- ___ Python tracker ___

[issue41984] Empty __slots__ can create untracked reference cycles

Brandt Bucher added the comment: > there is gc.untrack() I'm not sure that's true... :) Although perhaps track()/untrack() functions *could* be useful to add to the gc module... but that's a separate conversation. -- ___ Python tracker

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: > I think I can just create a simple utility in _testcapi to untrack instances > for this purpose. I have the feeling that I am misunderstanding what you refer to, but if is **untrack** what you need, there is gc.untrack() --

[issue41984] Empty __slots__ can create untracked reference cycles

Brandt Bucher added the comment: No problem. I just need to rework some hacks in test_finalization where we use empty __slots__ to create non-GC types. I think I can just create a simple utility in _testcapi to untrack instances for this purpose. --

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: Thanks a lot, Brandt for doing the benchmarking! I think that unpack_sequence is **very** affected by code locality. I was debugging it recently with Linux perf (https://perf.wiki.kernel.org/index.php/Main_Page) and it shows that is extremely

[issue41984] Empty __slots__ can create untracked reference cycles

Brandt Bucher added the comment: Using the following patch: https://github.com/python/cpython/compare/master...brandtbucher:track-all-heap-types I got the following pyperformance results (with PGO/LTO and CPU isolation, insignificant rows omitted):

[issue42015] Order of decrementing reference counts in meth_dealloc

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue42015] Order of decrementing reference counts in meth_dealloc

Henry Schreiner added the comment: I tested before the patch, and I got 17 segfaults running a pybind11 module 20 times. After the patch, I ran about 50 times and had no segfaults! -- ___ Python tracker

[issue42015] Order of decrementing reference counts in meth_dealloc

miss-islington added the comment: New changeset 8a12503b4532e33d590ecea7eb94cd0e6b0f1488 by Miss Skeleton (bot) in branch '3.9': bpo-42015: Reorder dereferencing calls in meth_dealloc, to make sure m_self is kept alive long enough (GH-22670)

[issue42015] Order of decrementing reference counts in meth_dealloc

Change by miss-islington : -- nosy: +miss-islington nosy_count: 3.0 -> 4.0 pull_requests: +21648 pull_request: https://github.com/python/cpython/pull/22674 ___ Python tracker

[issue42015] Order of decrementing reference counts in meth_dealloc

Serhiy Storchaka added the comment: New changeset 04b8631d84a870dda456ef86039c1baf34d08500 by Yannick Jadoul in branch 'master': bpo-42015: Reorder dereferencing calls in meth_dealloc, to make sure m_self is kept alive long enough (GH-22670)

[issue42015] Order of decrementing reference counts in meth_dealloc

Serhiy Storchaka added the comment: Thank you Yannick for your report and PR! -- ___ Python tracker ___ ___ Python-bugs-list

[issue42015] Order of decrementing reference counts in meth_dealloc

Yannick Jadoul added the comment: Yes, sorry for the delay; I got caught up in something else. Meanwhile, https://github.com/python/cpython/pull/22670 should solve our issues. I think Henry confirmed this locally? -- ___ Python tracker

[issue42015] Order of decrementing reference counts in meth_dealloc

Change by Yannick Jadoul : -- keywords: +patch pull_requests: +21643 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22670 ___ Python tracker ___

[issue42015] Order of decrementing reference counts in meth_dealloc

Serhiy Storchaka added the comment: Do you mind to create a PR Yannick? -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue42015] Order of decrementing reference counts in meth_dealloc

Change by Henry Schreiner : -- nosy: +Henry Schreiner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42015] Order of decrementing reference counts in meth_dealloc

pybind11 issue: https://github.com/pybind/pybind11/issues/2558 - pybind11 PR: https://github.com/pybind/pybind11/pull/2576 -- components: C API, Interpreter Core messages: 378500 nosy: YannickJadoul priority: normal severity: normal status: open title: Order of decrementing reference counts

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: > I’m just not sure I see a way to fix this without tracking them all. IIRC we do skip the GC flags for user-created types only when the subtype is not adding new variables *and* the base class is not a GC class by itself. This includes the case with

[issue41984] Empty __slots__ can create untracked reference cycles

Brandt Bucher added the comment: > Maybe I am missing something but we could mark them as having GC support > unconditionally but still leave them untracking and unconditionally add a > tracking call on setattribute. Hm, I’m not sure that would be enough. Consider the case of a class that

[issue41984] Empty __slots__ can create untracked reference cycles

Pablo Galindo Salgado added the comment: Thanks for noticing this, Brandt! > The fix is simple: track all instances of user-defined classes, no exceptions I have the fear that this may increase the time of collections substantially because even if many of them won't have references at all,

<    1   2   3   4   5   6   7   8   9   10   >