[issue6116] frame.f_locals keeps references to things for too long

Benjamin Peterson added the comment: I tried making f_locals always a copy but it wreaks havoc with some code which expects changing it to "work", namely pdb. I resign myself to using weakrefs. -- ___ Python tracker

[issue6116] frame.f_locals keeps references to things for too long

Antoine Pitrou added the comment: Le jeudi 05 mai 2011 à 18:45 +, Facundo Batista a écrit : > > Antoine, to see if I understood correctly... if we build the dict, and > just return it but don't save it in the frame, this leak would be > solved? (yes, it'd be slower because everytime it's as

[issue6116] frame.f_locals keeps references to things for too long

Facundo Batista added the comment: Antoine, to see if I understood correctly... if we build the dict, and just return it but don't save it in the frame, this leak would be solved? (yes, it'd be slower because everytime it's asked, it'd need to be built again) -- _

[issue6116] frame.f_locals keeps references to things for too long

Benjamin Peterson added the comment: I vote for option 1. We already eschew hacks with locals(). -- nosy: +benjamin.peterson ___ Python tracker ___ __

[issue6116] frame.f_locals keeps references to things for too long

Antoine Pitrou added the comment: > Making a copy of f_locals values to return a dictionary that doesn't > hold references to the locals of the frame is not that simple I think you misunderstood the bug report. The issue here is not that locals are referenced from the dict, it's that the dict

[issue6116] frame.f_locals keeps references to things for too long

Facundo Batista added the comment: Making a copy of f_locals values to return a dictionary that doesn't hold references to the locals of the frame is not that simple (for me, at least): - shallow copy: we'll return always a new dict, with the values being a copy of locals; this is simpler, bu

[issue6116] frame.f_locals keeps references to things for too long

Antoine Pitrou added the comment: > Regarding the first solution, my only question right now is whether this > should be a new attribute/method, or if the behavior of f_locals should > just be changed. The former would be nicer, I think, and perhaps > f_locals can be deprecated in favor of it.

[issue6116] frame.f_locals keeps references to things for too long

Jean-Paul Calderone added the comment: Oh, I forgot dictionaries aren't weakrefable. That's such a pain, I thought the third solution would be a good balance between easy and good. :/ Regarding the first solution, my only question right now is whether this should be a new attribute/method, or

[issue6116] frame.f_locals keeps references to things for too long

Antoine Pitrou added the comment: IMO, any of these three solutions should be accepted. The second is of course the nicest but also the most complex one, and it's probably not worth it. I'm not sure the third solution is easily feasible given that dicts currently don't accept weakref'ing. We cou

[issue6116] frame.f_locals keeps references to things for too long

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue6116] frame.f_locals keeps references to things for too long

New submission from Jean-Paul Calderone : When a frame's f_locals attribute is accessed, one of two things happens: * If this is the first access, a new dictionary is created and it is populated with the locals from the frame (since they are not stored internally as a dictionary). The diction