Debugging confusion -- too many stacks!

[Tim Peters]

[Jason Stokes]
> 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