by the frameobject dealloc when it is time for the locals to go. When
there's still a traceback object referencing this stack frame, we
don't want the local variables to disappear yet.
(Hmm... Shouldn't they be copied to the f_locals dictionary?)
- Use co->... instead of f->f_code->...; save an extra lookup of what
we already have in a local variable).
- Remove test for nlocals > 0 before setting fastlocals to
f->f_localsplus; 0 is a rare case and the assignment is safe even
then.
called with keyword arguments -- the keyword and value were leaked.
This affected for instance with a __call__() method.
Bug reported and fix supplied by Jim Fulton.
i.e., counting opcode frequencies, or (with DXPAIRS defined) opcode
pair frequencies. Define DYNAMIC_EXECUTION_PROFILE on the command
line (for this file and for sysmodule.c) to enable.
table which is incorporated in the code object. This way, the runtime
overhead to keep track of line numbers is only incurred when an
exception has to be reported.
This is safe now that both intrcheck() and signalmodule.c schedule a
sigcheck() call via Py_AddPendingCall().
This gives another 7% speedup (never run such a test twice ;-).
to PyCode_New() argument list. Move MAXBLOCKS constant to conpile.h.
Added accurate calculation of the actual stack size needed by the
generated code.
Also commented out all fprintf statements (except for a new one to
diagnose stack underflow, and one in #ifdef'ed out code), and added
some new TO DO suggestions (now that the stacksize is taken of the TO
DO list).
The raise logic has one additional feature: if you raise <class>,
<value> where <value> is not an instance, it will construct an
instance using <value> as argument. If <value> is None, <class> is
instantiated without arguments. If <value> is a tuple, it is used as
the argument list.
This feature is intended to make it easier to upgrade code from using
string exceptions to using class exceptions; without this feature,
you'd have to change every raise statement from ``raise X'' to ``raise
X()'' and from ``raise X, y'' to ``raise X(y)''. The latter is still
the recommended form (because it has no ambiguities about the number
of arguments), but this change makes the transition less painful.
be Ellipsis!).
Bumped the API version because a linker-visible symbol is affected.
Old C code will still compile -- there's a b/w compat macro.
Similarly, old Python code will still run, builtin exports both
Ellipses and Ellipsis.
Guido van Rossum