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 it works. It seems to depend on unguaranteed
implementation details: PyObject_ClearWeakRefs() copies all weakrefs with
callbacks to a tuple before invoking callbacks. If this were not the case
then I think the weakref you created (which is scheduled to fire second) would
be garbage collected before its callback could be invoked.
I think users should have a documented way to schedule callbacks without having
to
explicitly save the weakref.
> For point 2 Antoine has noted that it is a known issue and there is a
> solution
> (issue812369).
That has been languishing for 9 years. I would not hold your breath.
> > http://docs.python.org/py3k/reference/datamodel.html#object.__del__
> >
> > which also applies to weakref callbacks.
>
> Is this your point 2?
Yes.
> Relying on GC is dangerous thing for resource releasing. And it even more
> dangerous for alternative implementations without reference counting. That is
> why in recent times in Python there has been a tendency to RAII strategy
> (context managers).
I agree that explicit clean up using context managers to be strongly encouraged.
But resources should still be released if the object is garbage collected. Or
do you think that file objects should stop bothering to close their fds when
they
are deallocated?
> Can you give examples, where the use of finalize necessary or more convenient
> the other ways?
multiprocessing (which I orginally wrote) makes extensive use of finalizers,
(although with a different implementation and api). In some cases that is
because
at the time I wanted to support versions of Python which did not have the with
statement.
But there are various things there that depend on finalizers, and on being able
to guarantee that they get called on exit (in a predictable order).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15528>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
