2019-05-17 06:55:34 -03:00
|
|
|
.. highlight:: c
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
|
2016-06-02 20:26:51 -03:00
|
|
|
.. index:: object; code, code object
|
|
|
|
|
2022-09-19 10:32:51 -03:00
|
|
|
.. _codeobjects:
|
|
|
|
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
Code Objects
|
|
|
|
------------
|
|
|
|
|
|
|
|
.. sectionauthor:: Jeffrey Yasskin <jyasskin@gmail.com>
|
|
|
|
|
|
|
|
Code objects are a low-level detail of the CPython implementation.
|
|
|
|
Each one represents a chunk of executable code that hasn't yet been
|
|
|
|
bound into a function.
|
|
|
|
|
2010-10-06 07:11:56 -03:00
|
|
|
.. c:type:: PyCodeObject
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
|
|
|
|
The C structure of the objects used to describe code objects. The
|
|
|
|
fields of this type are subject to change at any time.
|
|
|
|
|
|
|
|
|
2010-10-06 07:11:56 -03:00
|
|
|
.. c:var:: PyTypeObject PyCode_Type
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
|
2010-10-06 07:11:56 -03:00
|
|
|
This is an instance of :c:type:`PyTypeObject` representing the Python
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
:class:`code` type.
|
|
|
|
|
|
|
|
|
2010-10-06 07:11:56 -03:00
|
|
|
.. c:function:: int PyCode_Check(PyObject *co)
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
|
2021-01-06 07:38:26 -04:00
|
|
|
Return true if *co* is a :class:`code` object. This function always succeeds.
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
|
2012-06-03 02:07:47 -03:00
|
|
|
.. c:function:: int PyCode_GetNumFree(PyCodeObject *co)
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
|
|
|
|
Return the number of free variables in *co*.
|
|
|
|
|
2023-07-29 14:41:40 -03:00
|
|
|
.. c:function:: PyCodeObject* PyUnstable_Code_New(int argcount, int kwonlyargcount, int nlocals, int stacksize, int flags, PyObject *code, PyObject *consts, PyObject *names, PyObject *varnames, PyObject *freevars, PyObject *cellvars, PyObject *filename, PyObject *name, PyObject *qualname, int firstlineno, PyObject *linetable, PyObject *exceptiontable)
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
|
2019-07-01 07:35:05 -03:00
|
|
|
Return a new code object. If you need a dummy code object to create a frame,
|
2023-02-28 04:31:01 -04:00
|
|
|
use :c:func:`PyCode_NewEmpty` instead.
|
|
|
|
|
|
|
|
Since the definition of the bytecode changes often, calling
|
2023-07-26 20:41:15 -03:00
|
|
|
:c:func:`PyUnstable_Code_New` directly can bind you to a precise Python version.
|
2023-02-28 04:31:01 -04:00
|
|
|
|
|
|
|
The many arguments of this function are inter-dependent in complex
|
2022-04-21 15:08:36 -03:00
|
|
|
ways, meaning that subtle changes to values are likely to result in incorrect
|
|
|
|
execution or VM crashes. Use this function only with extreme care.
|
2019-05-31 15:33:41 -03:00
|
|
|
|
2022-04-21 15:08:36 -03:00
|
|
|
.. versionchanged:: 3.11
|
2023-07-29 14:41:40 -03:00
|
|
|
Added ``qualname`` and ``exceptiontable`` parameters.
|
2022-04-21 15:08:36 -03:00
|
|
|
|
2023-02-28 04:31:01 -04:00
|
|
|
.. index:: single: PyCode_New
|
|
|
|
|
|
|
|
.. versionchanged:: 3.12
|
|
|
|
|
|
|
|
Renamed from ``PyCode_New`` as part of :ref:`unstable-c-api`.
|
|
|
|
The old name is deprecated, but will remain available until the
|
|
|
|
signature changes again.
|
|
|
|
|
2023-07-29 14:41:40 -03:00
|
|
|
.. c:function:: PyCodeObject* PyUnstable_Code_NewWithPosOnlyArgs(int argcount, int posonlyargcount, int kwonlyargcount, int nlocals, int stacksize, int flags, PyObject *code, PyObject *consts, PyObject *names, PyObject *varnames, PyObject *freevars, PyObject *cellvars, PyObject *filename, PyObject *name, PyObject *qualname, int firstlineno, PyObject *linetable, PyObject *exceptiontable)
|
2019-07-01 07:35:05 -03:00
|
|
|
|
2023-07-26 20:41:15 -03:00
|
|
|
Similar to :c:func:`PyUnstable_Code_New`, but with an extra "posonlyargcount" for positional-only arguments.
|
|
|
|
The same caveats that apply to ``PyUnstable_Code_New`` also apply to this function.
|
2019-07-01 07:35:05 -03:00
|
|
|
|
2023-02-28 04:31:01 -04:00
|
|
|
.. index:: single: PyCode_NewWithPosOnlyArgs
|
|
|
|
|
|
|
|
.. versionadded:: 3.8 as ``PyCode_NewWithPosOnlyArgs``
|
2019-07-01 07:35:05 -03:00
|
|
|
|
2022-04-21 15:08:36 -03:00
|
|
|
.. versionchanged:: 3.11
|
2023-07-29 14:41:40 -03:00
|
|
|
Added ``qualname`` and ``exceptiontable`` parameters.
|
2022-04-21 15:08:36 -03:00
|
|
|
|
2023-02-28 04:31:01 -04:00
|
|
|
.. versionchanged:: 3.12
|
|
|
|
|
|
|
|
Renamed to ``PyUnstable_Code_NewWithPosOnlyArgs``.
|
|
|
|
The old name is deprecated, but will remain available until the
|
|
|
|
signature changes again.
|
|
|
|
|
2012-06-03 02:07:47 -03:00
|
|
|
.. c:function:: PyCodeObject* PyCode_NewEmpty(const char *filename, const char *funcname, int firstlineno)
|
Merged revisions 72487-72488,72879 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
2009-07-21 01:30:03 -03:00
|
|
|
|
|
|
|
Return a new empty code object with the specified filename,
|
2022-04-21 15:08:36 -03:00
|
|
|
function name, and first line number. The resulting code
|
|
|
|
object will raise an ``Exception`` if executed.
|
2021-04-02 09:24:57 -03:00
|
|
|
|
|
|
|
.. c:function:: int PyCode_Addr2Line(PyCodeObject *co, int byte_offset)
|
|
|
|
|
|
|
|
Return the line number of the instruction that occurs on or before ``byte_offset`` and ends after it.
|
|
|
|
If you just need the line number of a frame, use :c:func:`PyFrame_GetLineNumber` instead.
|
|
|
|
|
|
|
|
For efficiently iterating over the line numbers in a code object, use `the API described in PEP 626
|
2022-03-30 08:00:27 -03:00
|
|
|
<https://peps.python.org/pep-0626/#out-of-process-debuggers-and-profilers>`_.
|
2021-07-12 21:29:39 -03:00
|
|
|
|
|
|
|
.. c:function:: int PyCode_Addr2Location(PyObject *co, int byte_offset, int *start_line, int *start_column, int *end_line, int *end_column)
|
|
|
|
|
|
|
|
Sets the passed ``int`` pointers to the source code line and column numbers
|
|
|
|
for the instruction at ``byte_offset``. Sets the value to ``0`` when
|
|
|
|
information is not available for any particular element.
|
|
|
|
|
|
|
|
Returns ``1`` if the function succeeds and 0 otherwise.
|
2022-05-03 10:13:13 -03:00
|
|
|
|
2023-02-03 23:33:28 -04:00
|
|
|
.. versionadded:: 3.11
|
|
|
|
|
2022-05-03 10:13:13 -03:00
|
|
|
.. c:function:: PyObject* PyCode_GetCode(PyCodeObject *co)
|
|
|
|
|
|
|
|
Equivalent to the Python code ``getattr(co, 'co_code')``.
|
|
|
|
Returns a strong reference to a :c:type:`PyBytesObject` representing the
|
|
|
|
bytecode in a code object. On error, ``NULL`` is returned and an exception
|
|
|
|
is raised.
|
|
|
|
|
|
|
|
This ``PyBytesObject`` may be created on-demand by the interpreter and does
|
|
|
|
not necessarily represent the bytecode actually executed by CPython. The
|
|
|
|
primary use case for this function is debuggers and profilers.
|
|
|
|
|
|
|
|
.. versionadded:: 3.11
|
|
|
|
|
2022-08-04 10:53:31 -03:00
|
|
|
.. c:function:: PyObject* PyCode_GetVarnames(PyCodeObject *co)
|
|
|
|
|
|
|
|
Equivalent to the Python code ``getattr(co, 'co_varnames')``.
|
|
|
|
Returns a new reference to a :c:type:`PyTupleObject` containing the names of
|
|
|
|
the local variables. On error, ``NULL`` is returned and an exception
|
|
|
|
is raised.
|
|
|
|
|
|
|
|
.. versionadded:: 3.11
|
|
|
|
|
|
|
|
.. c:function:: PyObject* PyCode_GetCellvars(PyCodeObject *co)
|
|
|
|
|
|
|
|
Equivalent to the Python code ``getattr(co, 'co_cellvars')``.
|
|
|
|
Returns a new reference to a :c:type:`PyTupleObject` containing the names of
|
|
|
|
the local variables that are referenced by nested functions. On error, ``NULL``
|
|
|
|
is returned and an exception is raised.
|
|
|
|
|
|
|
|
.. versionadded:: 3.11
|
|
|
|
|
|
|
|
.. c:function:: PyObject* PyCode_GetFreevars(PyCodeObject *co)
|
|
|
|
|
|
|
|
Equivalent to the Python code ``getattr(co, 'co_freevars')``.
|
|
|
|
Returns a new reference to a :c:type:`PyTupleObject` containing the names of
|
|
|
|
the free variables. On error, ``NULL`` is returned and an exception is raised.
|
|
|
|
|
|
|
|
.. versionadded:: 3.11
|
2022-12-02 13:28:27 -04:00
|
|
|
|
|
|
|
.. c:function:: int PyCode_AddWatcher(PyCode_WatchCallback callback)
|
|
|
|
|
|
|
|
Register *callback* as a code object watcher for the current interpreter.
|
|
|
|
Return an ID which may be passed to :c:func:`PyCode_ClearWatcher`.
|
|
|
|
In case of error (e.g. no more watcher IDs available),
|
|
|
|
return ``-1`` and set an exception.
|
|
|
|
|
|
|
|
.. versionadded:: 3.12
|
|
|
|
|
|
|
|
.. c:function:: int PyCode_ClearWatcher(int watcher_id)
|
|
|
|
|
|
|
|
Clear watcher identified by *watcher_id* previously returned from
|
|
|
|
:c:func:`PyCode_AddWatcher` for the current interpreter.
|
|
|
|
Return ``0`` on success, or ``-1`` and set an exception on error
|
|
|
|
(e.g. if the given *watcher_id* was never registered.)
|
|
|
|
|
|
|
|
.. versionadded:: 3.12
|
|
|
|
|
|
|
|
.. c:type:: PyCodeEvent
|
|
|
|
|
|
|
|
Enumeration of possible code object watcher events:
|
|
|
|
- ``PY_CODE_EVENT_CREATE``
|
|
|
|
- ``PY_CODE_EVENT_DESTROY``
|
|
|
|
|
|
|
|
.. versionadded:: 3.12
|
|
|
|
|
|
|
|
.. c:type:: int (*PyCode_WatchCallback)(PyCodeEvent event, PyCodeObject* co)
|
|
|
|
|
|
|
|
Type of a code object watcher callback function.
|
|
|
|
|
|
|
|
If *event* is ``PY_CODE_EVENT_CREATE``, then the callback is invoked
|
|
|
|
after `co` has been fully initialized. Otherwise, the callback is invoked
|
|
|
|
before the destruction of *co* takes place, so the prior state of *co*
|
|
|
|
can be inspected.
|
|
|
|
|
2023-03-07 20:10:58 -04:00
|
|
|
If *event* is ``PY_CODE_EVENT_DESTROY``, taking a reference in the callback
|
|
|
|
to the about-to-be-destroyed code object will resurrect it and prevent it
|
|
|
|
from being freed at this time. When the resurrected object is destroyed
|
|
|
|
later, any watcher callbacks active at that time will be called again.
|
|
|
|
|
2022-12-02 13:28:27 -04:00
|
|
|
Users of this API should not rely on internal runtime implementation
|
|
|
|
details. Such details may include, but are not limited to, the exact
|
|
|
|
order and timing of creation and destruction of code objects. While
|
|
|
|
changes in these details may result in differences observable by watchers
|
|
|
|
(including whether a callback is invoked or not), it does not change
|
|
|
|
the semantics of the Python code being executed.
|
|
|
|
|
2023-03-07 20:10:58 -04:00
|
|
|
If the callback sets an exception, it must return ``-1``; this exception will
|
|
|
|
be printed as an unraisable exception using :c:func:`PyErr_WriteUnraisable`.
|
|
|
|
Otherwise it should return ``0``.
|
|
|
|
|
|
|
|
There may already be a pending exception set on entry to the callback. In
|
|
|
|
this case, the callback should return ``0`` with the same exception still
|
|
|
|
set. This means the callback may not call any other API that can set an
|
|
|
|
exception unless it saves and clears the exception state first, and restores
|
|
|
|
it before returning.
|
2022-12-02 13:28:27 -04:00
|
|
|
|
|
|
|
.. versionadded:: 3.12
|
2023-02-28 04:31:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
Extra information
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
To support low-level extensions to frame evaluation, such as external
|
|
|
|
just-in-time compilers, it is possible to attach arbitrary extra data to
|
|
|
|
code objects.
|
|
|
|
|
|
|
|
These functions are part of the unstable C API tier:
|
|
|
|
this functionality is a CPython implementation detail, and the API
|
|
|
|
may change without deprecation warnings.
|
|
|
|
|
|
|
|
.. c:function:: Py_ssize_t PyUnstable_Eval_RequestCodeExtraIndex(freefunc free)
|
|
|
|
|
|
|
|
Return a new an opaque index value used to adding data to code objects.
|
|
|
|
|
|
|
|
You generally call this function once (per interpreter) and use the result
|
|
|
|
with ``PyCode_GetExtra`` and ``PyCode_SetExtra`` to manipulate
|
|
|
|
data on individual code objects.
|
|
|
|
|
|
|
|
If *free* is not ``NULL``: when a code object is deallocated,
|
|
|
|
*free* will be called on non-``NULL`` data stored under the new index.
|
|
|
|
Use :c:func:`Py_DecRef` when storing :c:type:`PyObject`.
|
|
|
|
|
|
|
|
.. index:: single: _PyEval_RequestCodeExtraIndex
|
|
|
|
|
|
|
|
.. versionadded:: 3.6 as ``_PyEval_RequestCodeExtraIndex``
|
|
|
|
|
|
|
|
.. versionchanged:: 3.12
|
|
|
|
|
|
|
|
Renamed to ``PyUnstable_Eval_RequestCodeExtraIndex``.
|
|
|
|
The old private name is deprecated, but will be available until the API
|
|
|
|
changes.
|
|
|
|
|
|
|
|
.. c:function:: int PyUnstable_Code_GetExtra(PyObject *code, Py_ssize_t index, void **extra)
|
|
|
|
|
|
|
|
Set *extra* to the extra data stored under the given index.
|
|
|
|
Return 0 on success. Set an exception and return -1 on failure.
|
|
|
|
|
|
|
|
If no data was set under the index, set *extra* to ``NULL`` and return
|
|
|
|
0 without setting an exception.
|
|
|
|
|
|
|
|
.. index:: single: _PyCode_GetExtra
|
|
|
|
|
|
|
|
.. versionadded:: 3.6 as ``_PyCode_GetExtra``
|
|
|
|
|
|
|
|
.. versionchanged:: 3.12
|
|
|
|
|
|
|
|
Renamed to ``PyUnstable_Code_GetExtra``.
|
|
|
|
The old private name is deprecated, but will be available until the API
|
|
|
|
changes.
|
|
|
|
|
|
|
|
.. c:function:: int PyUnstable_Code_SetExtra(PyObject *code, Py_ssize_t index, void *extra)
|
|
|
|
|
|
|
|
Set the extra data stored under the given index to *extra*.
|
|
|
|
Return 0 on success. Set an exception and return -1 on failure.
|
|
|
|
|
|
|
|
.. index:: single: _PyCode_SetExtra
|
|
|
|
|
|
|
|
.. versionadded:: 3.6 as ``_PyCode_SetExtra``
|
|
|
|
|
|
|
|
.. versionchanged:: 3.12
|
|
|
|
|
|
|
|
Renamed to ``PyUnstable_Code_SetExtra``.
|
|
|
|
The old private name is deprecated, but will be available until the API
|
|
|
|
changes.
|