Ł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:
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
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 rep...@bugs.python.org
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
Antoine Pitrou added the comment:
Well, assuming there are no significant changes in the code (I haven't
checked), +1 for committing.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15528
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 rep...@bugs.python.org
http://bugs.python.org/issue15528
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
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 exec_prefix
Consider setting $PYTHONHOME to prefix[:exec_prefix]
Fatal Python error: Py_Initialize:
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
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15528
___
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 rep...@bugs.python.org
http://bugs.python.org/issue15528
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
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:
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
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
handler
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 rep...@bugs.python.org
http://bugs.python.org/issue15528
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.
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15528
___
___
Python-bugs-list mailing list
Richard Oudkerk added the comment:
New patch.
--
Added file: http://bugs.python.org/file26900/finalize.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15528
___
Richard Oudkerk added the comment:
Updated patch.
--
Added file: http://bugs.python.org/file26879/finalize.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15528
___
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 rep...@bugs.python.org
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
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15528
___
___
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:
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
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
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.
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 me.
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 and
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 that
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
31 matches
Mail list logo
