Armin Rigo wrote: ... [stuff agreed]
In this point of view, you can only call a function object (not a code object), but the function object needs to call a method build_frame() on the code object to create the appropriate kind of frame object. The resulting frame object should then have an eval() method to be actually run. I'm not sure where exactly the ExecutionContext comes into play; its role is to store the frames in the frame stack, but in Python built-in functions do not register frames there. Maybe it should be the role of the specific PyFrame class (implementing an app-level frame) to register and unregister itself into the frame stack. And what about generators ? I guess it would be nice if built-in functions could act as generators as well.
Maybe I've read not enough of context, but if I only can call a function object, how are then classes and complete modules executed? In standard Python, a frame is created for a code object, together with parameters and additional info, which may, but needn't come from a function object (speaking of closures). Why not stick with this? ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/