[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: > PJE suggests importing atexit and registering finalize only when it's > actually used. I guess this would be the easiest workaround. Done. -- status: open -> closed ___ Python tracker

[issue15528] Better support for finalization with weakrefs

Roundup Robot added the comment: New changeset d6ad9d7468f7 by Richard Oudkerk in branch 'default': Issue #15528: Delay importing atexit until weakref.finalize() used. http://hg.python.org/cpython/rev/d6ad9d7468f7 -- ___ Python tracker

[issue15528] Better support for finalization with weakrefs

Łukasz Langa added the comment: Your patch leaks references with subinterpreters, which was exposed by functools.singledispatch using weakref. While the actual bug is in atexit (which doesn't properly unregister on subinterpreter termination), now all uses of weakref leak. Context: http://mai

[issue15528] Better support for finalization with weakrefs

Changes by Richard Oudkerk : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue15528] Better support for finalization with weakrefs

Roundup Robot added the comment: New changeset 186cf551dae5 by Richard Oudkerk in branch 'default': Issue #15528: Add weakref.finalize to support finalization using http://hg.python.org/cpython/rev/186cf551dae5 -- ___ Python tracker

[issue15528] Better support for finalization with weakrefs

STINNER Victor added the comment: The changeset 2e446e87ac5b broke some buildbots at compile step. ./python -E -S -m sysconfig --generate-posix-vars Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Fatal Python error: Py_Initialize: can't initialize sys standard s

[issue15528] Better support for finalization with weakrefs

Roundup Robot added the comment: New changeset 2e446e87ac5b by Richard Oudkerk in branch 'default': Issue #15528: Add weakref.finalize to support finalization using http://hg.python.org/cpython/rev/2e446e87ac5b -- nosy: +python-dev ___ Python tracker

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: The only (non-doc, non-comment) changes were the two one-liners you suggested in msg172077. So I will commit. -- ___ Python tracker ___ _

[issue15528] Better support for finalization with weakrefs

Antoine Pitrou added the comment: Well, assuming there are no significant changes in the code (I haven't checked), +1 for committing. -- ___ Python tracker ___ _

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: Here is an updated patch. It is only really the example in the docs which is different, plus a note about daemon threads. Antoine, do think this is ready to be committed? -- Added file: http://bugs.python.org/file30140/finalize.patch ___

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: > In any case, I think it's just something we'll have to live with. Daemon > threads are not a terrific idea in general. I agree. -- ___ Python tracker __

[issue15528] Better support for finalization with weakrefs

Antoine Pitrou added the comment: > But in Py_Finalize(), call_py_exitfuncs() is called *before* > _Py_Finalizing is set to a non-NULL value. > > > http://hg.python.org/cpython/file/0f827775f7b7/Python/pythonrun.c#l492 Ah, right. But is it any different from, e.g., registering an atexit handle

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: On 14/02/2013 3:16pm, Antoine Pitrou wrote: > Mmmh... thread switching is already blocked at shutdown: > http://hg.python.org/cpython/file/0f827775f7b7/Python/ceval.c#l434 But in Py_Finalize(), call_py_exitfuncs() is called *before* _Py_Finalizing is set to a

[issue15528] Better support for finalization with weakrefs

Antoine Pitrou added the comment: > Is it necessary/desirable to allow daemon threads to run during > shutdown. Maybe blocking thread switching at shutdown could cause > deadlocks? Mmmh... thread switching is already blocked at shutdown: http://hg.python.org/cpython/file/0f827775f7b7/Python/cev

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: > Richard, do you still want to push this forward? Otherwise I'd like to > finalize the patch (in the other sense ;-). I started to worry a bit about daemon threads. I think they can still run while atexit functions are being run.* So if a daemon thread cre

[issue15528] Better support for finalization with weakrefs

Antoine Pitrou added the comment: Richard, do you still want to push this forward? Otherwise I'd like to finalize the patch (in the other sense ;-). -- ___ Python tracker ___ __

[issue15528] Better support for finalization with weakrefs

Antoine Pitrou added the comment: In: +except: +sys.excepthook(*sys.exc_info()) I would write "except Exception" instead. You don't want to trap e.g. KeyboardInterrupt. For clarity, I would also add "_dirty = False" at the finalize top-level. Otherw

[issue15528] Better support for finalization with weakrefs

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: New patch. -- Added file: http://bugs.python.org/file26900/finalize.patch ___ Python tracker ___ __

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: Updated patch. -- Added file: http://bugs.python.org/file26879/finalize.patch ___ Python tracker ___ __

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: > In the latest patch, what are "broken" and "priority" for? They are for a subclass used by multiprocessing. But it is premature to worry about subclassing, so I will take them out. > Also, I would question why atexit is false by default. I would find it >

[issue15528] Better support for finalization with weakrefs

Antoine Pitrou added the comment: In the latest patch, what are "broken" and "priority" for? Also, I would question why atexit is false by default. I would find it personally less surprising to be true. -- ___ Python tracker

[issue15528] Better support for finalization with weakrefs

Changes by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: > In _make_callback, I still think the default error reporting mechanism > should be kept. It can be improved separately. New patch. This time I have got rid of _make_callback, and just given __call__ an ignored optional argument. -- Added file: htt

[issue15528] Better support for finalization with weakrefs

Antoine Pitrou added the comment: I don't understand why you have two names: finalize and Finalizer. Let's keep only one of them. isalive() could be a read-only property named "alive" instead. In _make_callback, I still think the default error reporting mechanism should be kept. It can be imp

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: Updated patch. get() and put() replaced by peek() and detach(). Added isalive(). Now finalizer class has no state, i.e. __slots__ == (). -- Added file: http://bugs.python.org/file26701/finalize.patch ___ Python t

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: > For point 1: global weakref.WeakKeyDictionary is good store for weak refs > with > callbacks. > > global weakdict > weakdict[kenny] = weakref.ref(kenny, lambda _: print("you killed kenny!")) That depends on kenny being hashable. It also surprises me a bit

[issue15528] Better support for finalization with weakrefs

Serhiy Storchaka added the comment: > finalize does not "compete" with contextlib.ExitStack, atexit and > weakref.WeakKeyDictionary. It only competes with __del__ and weakref > callbacks. What kind of problems you solve with __del__ and weakref callbacks? For most of them contextlib.ExitStack

[issue15528] Better support for finalization with weakrefs

Richard Oudkerk added the comment: > I don't quite understand the purpose of your suggestions. What can you do > with it help, what you can not do with contextlib.ExitStack, atexit, > __del__ method, weakref.WeakKeyDictionary or weakref.ref? I read the > documentation, but the meaning eludes m

[issue15528] Better support for finalization with weakrefs

Serhiy Storchaka added the comment: I don't quite understand the purpose of your suggestions. What can you do with it help, what you can not do with contextlib.ExitStack, atexit, __del__ method, weakref.WeakKeyDictionary or weakref.ref? I read the documentation, but the meaning eludes me. ---

[issue15528] Better support for finalization with weakrefs

New submission from Richard Oudkerk: A patch with docs and tests for the idea I suggested on python-ideas: http://comments.gmane.org/gmane.comp.python.ideas/15863 To repeat what I wrote there, the current issues with weakref callbacks include: 1. They are rather low level, and working out