Rocky Bernstein wrote:
> The below is a little long. So here's a summary.
> 
>  Ideally what I'd like in 1.9, 1.9.1 or 2.0:
>   * Frame/Block objects which contains 
>     - line, (may be nil)
>     - method, # of args  (may be nil)
>     - access to a binding object which we can eval for access to that 
> scope (not nil)
>     My understanding is this information is around at run time.
>  
>   * Thread Object which gives access to the Frame/Block above. So access 
> to the Frame object could be via a something like 
> thread.caller(level-number).
>  
>   * Enough added to the C-API added (e.g. parts of vm_core.h) to be able 
> to write code to do the above.

Be careful what you ask for.

Exposing call frames to the code is a neat, useful feature, to be sure. 
And Python's debugging capabilities use such access to great effect, 
inspecting the call stack and so on. But all is not wine and roses. 
Exposing call frames, scoping constructs, and so on prevents any 
implementation from minimizing or optimizing frames away. Many of the 
fastest language implementations and VMs (like the JVM, JRuby, and I 
believe Ruby 1.9) get that way because frames are not exposed and they 
can optimize them in different ways. In the JVM, a Java call may result 
in one, many, or even zero C call frames being constructed, and after 
more and more code gets inlined this metric will change.

IronPython, which boasts better performance than C Python in many cases, 
gets there largely because it does not support frame objects. The side 
effect is that you can't use any of the Python frame-inspecting tools 
with IronPython.

So yes, you may get good features out of having frames exposed to the 
language, but to my knowledge there's no implementation that does so and 
avoids paying a performance penalty for it.

JRuby could support such a feature, but I can tell you right now it 
would negatively impact performance, and we'd probably make it an 
optional flag so folks not interested in using the feature could run 
without it.

- Charlie