| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
global objects. (gh-30928)
We're no longer using _Py_IDENTIFIER() (or _Py_static_string()) in any core CPython code. It is still used in a number of non-builtin stdlib modules.
The replacement is: PyUnicodeObject (not pointer) fields under _PyRuntimeState, statically initialized as part of _PyRuntime. A new _Py_GET_GLOBAL_IDENTIFIER() macro facilitates lookup of the fields (along with _Py_GET_GLOBAL_STRING() for non-identifier strings).
https://bugs.python.org/issue46541#msg411799 explains the rationale for this change.
The core of the change is in:
* (new) Include/internal/pycore_global_strings.h - the declarations for the global strings, along with the macros
* Include/internal/pycore_runtime_init.h - added the static initializers for the global strings
* Include/internal/pycore_global_objects.h - where the struct in pycore_global_strings.h is hooked into _PyRuntimeState
* Tools/scripts/generate_global_objects.py - added generation of the global string declarations and static initializers
I've also added a --check flag to generate_global_objects.py (along with make check-global-objects) to check for unused global strings. That check is added to the PR CI config.
The remainder of this change updates the core code to use _Py_GET_GLOBAL_IDENTIFIER() instead of _Py_IDENTIFIER() and the related _Py*Id functions (likewise for _Py_GET_GLOBAL_STRING() instead of _Py_static_string()). This includes adding a few functions where there wasn't already an alternative to _Py*Id(), replacing the _Py_Identifier * parameter with PyObject *.
The following are not changed (yet):
* stop using _Py_IDENTIFIER() in the stdlib modules
* (maybe) get rid of _Py_IDENTIFIER(), etc. entirely -- this may not be doable as at least one package on PyPI using this (private) API
* (maybe) intern the strings during runtime init
https://bugs.python.org/issue46541
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add PRECALL_FUNCTION opcode.
* Move 'call shape' varaibles into struct.
* Replace CALL_NO_KW and CALL_KW with KW_NAMES and CALL instructions.
* Specialize for builtin methods taking using the METH_FASTCALL | METH_KEYWORDS protocol.
* Allow kwnames for specialized calls to builtin types.
* Specialize calls to tuple(arg) and str(arg).
|
|
|
|
| |
(GH-30751)
|
| |
|
|
|
|
|
|
|
|
| |
* Split YIELD_VALUE into ASYNC_GEN_WRAP; YIELD_VALUE for async generators.
* Split SEND into SEND; YIELD_VALUE.
* Document new opcodes.
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add RETURN_GENERATOR and JUMP_NO_INTERRUPT opcodes.
* Trim frame and generator by word each.
* Minor refactor of frame.c
* Update test.test_sys to account for smaller frames.
* Treat generator functions as normal functions when evaluating and specializing.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
(GH-30439)
Automerge-Triggered-By: GH:iritkatriel
|
|
|
|
| |
* Add a RESUME instruction to handle "call" events.
|
| |
|
| |
|
|
|
|
|
|
| |
* bpo-46202: remove opcode POP_EXCEPT_AND_RERAISE
* do not assume that an exception group is truthy
|
|
|
|
| |
changes. Move helpers to exceptions.c. Do not assume that exception groups are truthy. (GH-30289)
|
|
|
|
|
|
|
|
| |
* Do not PUSH/POP traceback or type to the stack as part of exc_info
* Remove exc_traceback and exc_type from _PyErr_StackItem
* Add to what's new, because this change breaks things like Cython
|
|
|
|
|
|
| |
* Split YIELD_FROM opcode into SEND and JUMP_ABSOLUTE.
* Remove YIELD_FROM opcode.
|
|
|
|
|
|
|
|
|
|
| |
* Add 3 new opcodes for calls: PRECALL_METHOD, CALL_NO_KW, CALL_KW.
* Update specialization to handle new CALL opcodes.
* Specialize call to method descriptors.
* Remove old CALL opcodes: CALL_FUNCTION, CALL_METHOD, CALL_METHOD_KW, CALL_FUNCTION_KW.
|
| |
|
|
|
|
|
|
|
| |
The line numbers of actually calling the decorator functions of
functions and classes was wrong (as opposed to loading them, were they
have been correct previously too).
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
|
|
|
| |
(The function this described was deleted by PR #23743, the comment was accidentally retained.)
|
|
|
|
|
|
|
|
|
|
|
| |
to be specialized (GH-29595)
* Make internal APIs that take PyFrameConstructor take a PyFunctionObject instead.
* Add reference to function to frame, borrow references to builtins and globals.
* Add COPY_FREE_VARS instruction to allow specialization of calls to inner functions.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
* Refactor mapping patterns and speed up class patterns.
* Simplify MATCH_KEYS and MATCH_CLASS.
* Add COPY opcode.
|
| |
|
| |
|
| |
|
|
|
|
| |
(#28262)
|
| |
|
|
|
|
| |
ADDOP_O(c, LOAD_CONST,...) (GH-28015)
|
|
|
| |
Automerge-Triggered-By: GH:pablogsal
|
| |
|
|
|
|
| |
after CFG optimization. (GH-27656)
|
| |
|
|
|
|
| |
blocks without line numbers (GH-27138)
|
|
|
|
| |
(GH-27160)
|
|
|
|
| |
keys (GH-27131)
|
|
|
|
| |
artificial (GH-27109)
|
|
|
|
|
| |
(GH-6766)
Co-authored-by: Pablo Galindo <pablogsal@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new resizing system works like this;
```
$ cat t.py
a + a + a + b + c + a + a + a + b + c + a + a + a + b + c + a + a + a + b + c
[repeated 99 more times]
$ ./python t.py
RESIZE: prev len = 32, new len = 66
FINAL SIZE: 56
-----------------------------------------------------
RESIZE: prev len = 32, new len = 66
RESIZE: prev len = 66, new len = 134
RESIZE: prev len = 134, new len = 270
RESIZE: prev len = 270, new len = 542
RESIZE: prev len = 542, new len = 1086
RESIZE: prev len = 1086, new len = 2174
RESIZE: prev len = 2174, new len = 4350
RESIZE: prev len = 4350, new len = 8702
FINAL SIZE: 8004
```
So now we do considerably lower number of `_PyBytes_Resize` calls.
Automerge-Triggered-By: GH:isidentical
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR is part of PEP 657 and augments the compiler to emit ending
line numbers as well as starting and ending columns from the AST
into compiled code objects. This allows bytecodes to be correlated
to the exact source code ranges that generated them.
This information is made available through the following public APIs:
* The `co_positions` method on code objects.
* The C API function `PyCode_Addr2Location`.
Co-authored-by: Batuhan Taskaya <isidentical@gmail.com>
Co-authored-by: Ammar Askar <ammar@ammaraskar.com>
|