On Wed, Apr 29, 2009 at 6:19 PM, Mike Krell <mbk.li...@gmail.com> wrote: > > On Wed, Apr 29, 2009 at 8:34 AM, Dino Viehland <di...@microsoft.com> wrote: >> Yep, we're going to make it available via a command line option. The >> Interesting question is what does IPython need from frames? Does it >> need locals (which frequently won't be available), globals, the function >> or code, or something else? > > I hadn't looked at the source until now, but a cursory glance suggests > that it typically wants to evaluate expressions with the locals (and > globals) from various stack frames. Could you discuss in a bit more > detail why certain locals wouldn't be available that would otherwise > be available in CPython?
I don't know the exact answer but I won't let that stop me from replying. :) I'll just rely on Dino correcting anything I say that is wrong... IronPython is a compiler that ultimately produces MSIL. If it determines that a particular local variable doesn't need to be accessed from outside the local scope -- that is, if it's not closed over and there is no exec or locals() which could target it -- then that variable simply becomes a local value on the IL stack. The CLR StackFrame object doesn't give us access to the associated locals, so we have no way of accessing them from outside (except through CLR debug APIs, which aren't really applicable for this type of use). In principle, IronPython could optionally use a less-efficient representation for locals that would allow us to expose them all of them through the Python stack frame. I don't know how serious a performance penalty this would exact, but I imagine it's not small. The Unladen Swallow project is likely to face similar tradeoffs. -- Curt Hagenlocher c...@hagenlocher.org _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
