[IronPython] sys._getframe(n)?

[Curt Hagenlocher]

On Wed, Apr 29, 2009 at 6:19 PM, Mike Krell <mbk.lists at gmail.com> wrote:
>
> On Wed, Apr 29, 2009 at 8:34 AM, Dino Viehland <dinov at 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
curt at hagenlocher.org