Debugging confusion -- too many stacks!
tim_one at email.msn.com
Sun Apr 2 01:18:21 EST 2000
> I'm confused about the difference between the C stack, the Frame
> stack, and the stack *inside* each execution frame.
The difference between the first two is an artifact of the current
implementation; indeed, getting rid of the distinction is the major point of
Christian Tismer's "Stackless" Python variant (where "less" refers to
getting rid of the C-stack component).
> From reading the source, I believe that each new code object gets a new
> frame allocated on the frame stack,
Each *invocation* of a code object, yes; and, e.g., if a function calls
itself recursively, there's only one code object but a separate frame for
each call level.
Note that in CT's Stackless Python, the frames actually form a tree
(although at any leaf, the path back to the root is unique and can be viewed
as a stack).
> within which is stored all kinds of useful information about the
> context the code is executing in -- the global and local environment,
> a tuple of constants, a tuple of arguments etc. *Within* each frame
> is *another* stack, upon which the Python virtual machine loads and
> manipulates intermediate values.
This is another artifact of the current implementation, and is best viewed
as an internal detail of no visible consequence.
> However, I'm not sure what the terminology is to refer to this
> third stack.
"The frame's eval stack" works for me <wink>.
> Understanding the distinction seems to be vital to using pdb, though.
I don't use pdb much, but don't see why this would be true. The frame's
eval stack is invisible, and the C and frame stacks happen to be intertwined
one-for-one today because a Python call happens to invoke the interpreter
recursively (at the C level) today. Conceptually, there's only one stack
involved in calls.
Perhaps you could be specific about what in pdb is confusing you, and
someone who uses it could straighten it out.
or-maybe-not-ly y'rs - tim
More information about the Python-list