| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Also complete cache effects for BINARY_SUBSCR family.
… include a file extension (pythonGH-99542)
There was an extra `>` in the url.
The sentence "Set the LC_CTYPE locale to the user preferred locale." should end with a period instead of a question mark.
Add some missing links to source from Python docs
…mantics_` (pythonGH-99285) It was untested and undocumented. No code has been found in the wild that ever used it.
…them (pythonGH-99215) Automerge-Triggered-By: GH:lysnikolaou
…on protocol (pythongh-99623) Describe the multiprocessing connection protocol. It isn't a good protocol, but it is what it is. This way we can more easily reason about making changes to it in a backwards compatible way.
…ines that fill the available buffer (python#99605)
Fix a number of compile errors with GCC-12 on macOS: 1. In pylifecycle.c the compile rejects _Pragma within a declaration 2. posixmodule.c was missing a number of ..._RUNTIME macros for non-clang on macOS 3. _ctypes assumed that __builtin_available is always present on macOS
) os.remove can raise PermissionError instead of IsADirectoryError, when the object to be removed is a directory (in particular on macOS). This reverts a change done in python#14262.
Fix a reference bug in _imp.create_builtin() after the creation of the first sub-interpreter for modules "builtins" and "sys".
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com> Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
…a Python.h (pythonGH-99014) The ``structmember.h`` header is deprecated, though it continues to be available and there are no plans to remove it. There are no deprecation warnings. Old code can stay unchanged (unless the extra include and non-namespaced macros bother you greatly). Specifically, no uses in CPython are updated -- that would just be unnecessary churn. The ``structmember.h`` header is deprecated, though it continues to be available and there are no plans to remove it. Its contents are now available just by including ``Python.h``, with a ``Py`` prefix added if it was missing: - `PyMemberDef`, `PyMember_GetOne` and`PyMember_SetOne` - Type macros like `Py_T_INT`, `Py_T_DOUBLE`, etc. (previously ``T_INT``, ``T_DOUBLE``, etc.) - The flags `Py_READONLY` (previously ``READONLY``) and `Py_AUDIT_READ` (previously all uppercase) Several items are not exposed from ``Python.h``: - `T_OBJECT` (use `Py_T_OBJECT_EX`) - `T_NONE` (previously undocumented, and pretty quirky) - The macro ``WRITE_RESTRICTED`` which does nothing. - The macros ``RESTRICTED`` and ``READ_RESTRICTED``, equivalents of `Py_AUDIT_READ`. - In some configurations, ``<stddef.h>`` is not included from ``Python.h``. It should be included manually when using ``offsetof()``. The deprecated header continues to provide its original contents under the original names. Your old code can stay unchanged, unless the extra include and non-namespaced macros bother you greatly. There is discussion on the issue to rename `T_PYSSIZET` to `PY_T_SSIZE` or similar. I chose not to do that -- users will probably copy/paste that with any spelling, and not renaming it makes migration docs simpler. Co-Authored-By: Alexander Belopolsky <abalkin@users.noreply.github.com> Co-Authored-By: Matthias Braun <MatzeB@users.noreply.github.com>
Without releasing the GIL calls to termios APIs might block the entire interpreter.
…ntation (python#99529) On some platforms, and in particular macOS/arm64, the calling convention for variadic arguments is different from the regular calling convention. Add a section to the documentation to document this.
…#99655) Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);" in longobject.c and _testcapi/long.c.
…unction is modified (python#98175)
Fix potential race condition in code patterns: * Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);" * Replace "Py_XDECREF(var); var = new;" with "Py_XSETREF(var, new);" * Replace "Py_CLEAR(var); var = new;" with "Py_XSETREF(var, new);" Other changes: * Replace "old = var; var = new; Py_DECREF(var)" with "Py_SETREF(var, new);" * Replace "old = var; var = new; Py_XDECREF(var)" with "Py_XSETREF(var, new);" * And remove the "old" variable.
Fix potential race condition in code patterns: * Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);" * Replace "Py_XDECREF(var); var = new;" with "Py_XSETREF(var, new);" * Replace "Py_CLEAR(var); var = new;" with "Py_XSETREF(var, new);" Other changes: * Replace "old = var; var = new; Py_DECREF(var)" with "Py_SETREF(var, new);" * Replace "old = var; var = new; Py_XDECREF(var)" with "Py_XSETREF(var, new);" * And remove the "old" variable.
Replace "Py_XDECREF(var); var = NULL;" with "Py_CLEAR(var);". Don't replace "Py_DECREF(var); var = NULL;" with "Py_CLEAR(var);". It would add an useless "if (var)" test in code path where var cannot be NULL.
…ongh-100203) We can't move it to _PyRuntimeState because the symbol is exposed in the stable ABI. We'll have to sort that out before a per-interpreter GIL, but it shouldn't be too hard. python#81057
…python#100177) pythongh-100176: Remove redundant compat code for Python 3.2 and older Python 3.2 has been EOL since 2016-02-20 and 2.7 since 2020-01-01, so we can remove this old compatibility check and unindent the old else-block. Also, in the unindented block, replace a .format() call with an f-string. Plus similar changes in the documentation.
…0254) * move _PyRuntime.global_objects.interned to _PyRuntime.cached_objects.interned_strings (and use _Py_CACHED_OBJECT()) * rename _PyRuntime.global_objects to _PyRuntime.static_objects (This also relates to pythongh-96075.) python#90111
…9998) * Initialize `type_watchers` array to `NULL`s * Optimize code watchers notification * Optimize func watchers notification
…100259) Typo introduced in python#100223. Automerge-Triggered-By: GH:brandtbucher
|
Obviously there's a git issue. I can sort it out later. The key thing is just the last commit. |
Sorry, something went wrong.
… input (python#100205) The presence of this macro indicates that a particular instruction may be considered for conversion to a register-based format (see faster-cpython/ideas#485). An invariant (currently unchecked) is that `DEOPT_IF()` may only occur *before* `DECREF_INPUTS()`, and `ERROR_IF()` may only occur *after* it. One reason not to check this is that there are a few places where we insert *two* `DECREF_INPUTS()` calls, in different branches of the code. The invariant checking would have to be able to do some flow control analysis to understand this. Note that many instructions, especially specialized ones, can't be converted to use this macro straightforwardly. This is because the generator currently only generates plain `Py_DECREF(variable)` statements, and cannot generate things like `_Py_DECREF_SPECIALIZED()` let alone deal with `_PyList_AppendTakeRef()`.
I updated only UNARY_POSITIVE_R to the new format.
- Syntax `register inst(NAME, (ieffects -- oeffects)) { ... }`
- Map stack effects from/to `REG(opargN)` instead of PEEK()
- Use `Py_XSETREF(REG(opargN), result)` for output effects
- Suppress stack adjustment in epilogue
- Suppress effect of `DECREF_INPUTS()`
- Always go to plain `error` in `ERROR_IF()`
|
Let me close this and create a new PR. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Here's a sketch of how to generate glue for register instructions. Lightly tested.