On Sep 18, 2017 07:58, "Antoine Pitrou" <anto...@python.org> wrote:
Le 18/09/2017 à 16:52, Guido van Rossum a écrit : > > In Python 2 the traceback was not part of the exception object because > there was (originally) no cycle GC. In Python GC we changed the awkward > interface to something more useful, because we could depend on GC. Why > are we now trying to roll back this feature? We should just improve GC. > (Or perhaps you shouldn't be raising so many exceptions. :-) Improving the GC is obviously a good thing, but what heuristic would you have in mind that may solve the issue at hand? I read the whole thread and I'm not sure what the issue at hand is :-). Obviously it's nice when the refcount system is able to implicitly clean things up in a prompt and deterministic way, but there are already tools to handle the cases where it doesn't (ResourceWarning, context managers, ...), and the more we encourage people to implicitly rely on refcounting, the harder it is to optimize the interpreter or use alternative language implementations. Why are reference cycles a problem that needs solving? Actually the bit that I find most confusing about Victor's story is, how can a traceback frame keep a thread alive? Is the problem that "dangling thread" warnings are being triggered by threads that are finished and dead but their Thread objects are still allocated? Because if so then that seems like a bug in the warnings mechanism; there's no harm in a dead Thread hanging around until collected, and Victor may have wasted a day debugging an issue that wasn't a problem in the first place... -n
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
