mirror of
https://github.com/python/cpython.git
synced 2026-04-14 15:50:50 +00:00
a005f323b7
* Add the c_init_default attribute which is used to initialize the C variable
if the default is not explicitly provided.
* Add the c_default_init() method which is used to derive c_default from
default if c_default is not explicitly provided.
* Explicit c_default and py_default are now almost always have precedence
over the generated value.
* Add support for bytes literals as default values.
* Improve support for str literals as default values (support non-ASCII
and non-printable characters and special characters like backslash or quotes).
* Fix support for str and bytes literals containing trigraphs, "/*" and "*/".
* Improve support for default values in converters "char" and "int(accept={str})".
* Converter "int(accept={str})" now requires 1-character string instead of
integer as default value.
* Add support for non-None default values in converter "Py_buffer": NULL,
str and bytes literals.
* Improve error handling for invalid default values.
* Rename Null to NullType for consistency.
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| c_analyzer | ||
| c_common | ||
| c_parser | ||
| cpython | ||
| distutils | ||
| c-analyzer.py | ||
| check-c-globals.py | ||
| must-resolve.sh | ||
| README | ||
| table-file.py | ||
| TODO | ||
####################################### # C Globals and CPython Runtime State. CPython's C code makes extensive use of global variables. Each global falls into one of several categories: * (effectively) constants (incl. static types) * globals used exclusively in main or in the REPL * freelists, caches, and counters * process-global state * module state * Python runtime state Of the different categories, the last two are problematic and generally should not exist in the codebase. Globals that hold module state (i.e. in Modules/*.c) cause problems when multiple interpreters are in use. For more info, see PEP 3121, which addresses the situation for extension modules in general. Globals in the last category should be avoided as well. The problem isn't with the Python runtime having state. Rather, the problem is with that state being spread throughout the codebase in dozens of individual globals. Unlike the other globals, the runtime state represents a set of values that are constantly shifting in a complex way. When they are spread out it's harder to get a clear picture of what the runtime involves. Furthermore, when they are spread out it complicates efforts that change the runtime. Consequently, the globals for Python's runtime state have been consolidated under a single top-level _PyRuntime global. No new globals should be added for runtime state. Instead, they should be added to _PyRuntimeState or one of its sub-structs. The check-c-globals script should be run to ensure that no new globals have been added: python3 Tools/c-analyzer/check-c-globals.py You can also use the more generic tool: python3 Tools/c-analyzer/c-analyzer.py If it reports any globals then they should be resolved. If the globals are runtime state then they should be folded into _PyRuntimeState.