This is a bug - f_locals / f_globals should be returning the module globals/locals but it's currently returning the locals for the actual compiled code.
I've opened bug 26243: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26243 There's apparently 1 other sys.settrace bug that needs to still be fixed for the final 2.6.1 release and I would guess this should be pretty easy to fix along w/ it - worst case we just need to pull the dictionary from the $codeContext variable. I would suggest checking for the $codeContext variable and pulling locals from it for the time being. If it's no there (because after fixing this it won't be) then I would just use the dictionary as-is. > -----Original Message----- > From: [email protected] [mailto:users- > [email protected]] On Behalf Of [email protected] > Sent: Thursday, February 18, 2010 12:26 AM > To: [email protected] > Subject: [IronPython] TraceBackFrame, f_globals, f_locals > > Hello, > > I'm helping a coworker embed IronPython with some debugging functions > into a C# app (following DevHawks example). > The thing I don't understand is how the f_globals and f_locals fields > work when executing the main script, neither contains the global/local > names in the top most scope, but do work correctly when executing a > function withing the same code scope. > > I know about the "$globalContext" name in the f_globals for the main > script, but would actually like to understand what's happening. > > Regards, > Avi. > > > > > -- > http://www.fastmail.fm - Does exactly what it says on the tin > > _______________________________________________ > Users mailing list > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
