10000 PEP 558: fix footnote references by hugovk · Pull Request #2754 · python/peps · GitHub
[go: up one dir, main page]
Skip to content

PEP 558: fix footnote references #2754

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Aug 17, 2022
Merged

PEP 558: fix footnote references #2754

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
f838e17
PEP 558: fix footnote references
hugovk Aug 8, 2022
af53b3d
PEP 558: Remove orphaned footnote
hugovk Aug 8, 2022
12f88e0
PEP 558: Remove redundant emacs metadata
hugovk Aug 8, 2022
df1f559
PEP 558: Fix code formatting
hugovk Aug 8, 2022
64234cd
PEP 558: Fix typos
hugovk Aug 8, 2022
3f66889
PEP 558: Update BPO redirects
hugovk Aug 8, 2022
ace825d
PEP 558: Convert to regular links
hugovk Aug 8, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
PEP 558: Fix code formatting
  • Loading branch information
@hugovk
hugovk committed Aug 8, 2022
commit df1f559409e7d6dbd66900ec6ae219654b4fd301
38 changes: 28 additions & 10 deletions pep-0558.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,9 @@ behaviour at function scope to make it more predictable and independent of the
presence or absence of tracing functions.

In addition, it proposes that the following functions be added to the stable
Python C API/ABI::
Python C API/ABI:

.. code-block:: c

typedef enum {
PyLocals_UNDEFINED = -1,
Expand Down Expand Up @@ -145,7 +147,7 @@ builtin to read as follows:
dictionaries.


There would also be a versionchanged note for the release making this change:
There would also be a ``versionchanged`` note for the release making this change:

In prior versions, the semantics of mutating the mapping object returned
from ``locals()`` were formally undefined. In CPython specifically,
Expand Down Expand Up @@ -273,14 +275,20 @@ Summary of proposed implementation-specific changes

* Changes are made as necessary to provide the updated Python level semantics
* Two new functions are added to the stable ABI to replicate the updated
behaviour of the Python ``locals()`` builtin::
behaviour of the Python ``locals()`` builtin:

.. code-block:: c

PyObject * PyLocals_Get();
PyLocals_Kind PyLocals_GetKind();

* One new function is added to the stable ABI to efficiently get a snapshot of
the local namespace in the running frame::
the local namespace in the running frame:

.. code-block:: c

PyObject * PyLocals_GetCopy();

* Corresponding frame accessor functions for these new public APIs are added to
the CPython frame C API
* On optimised frames, the Python level ``f_locals`` API will return dynamically
Expand Down Expand Up @@ -494,7 +502,9 @@ independent, behaviour. However, it is also desirable to allow C code to
exactly mimic the behaviour of Python code at the same scope.

To enable mimicking the behaviour of Python code, the stable C ABI would gain
the following new functions::
the following new functions:

.. code-block:: c

PyObject * PyLocals_Get();
PyLocals_Kind PyLocals_GetKind();
Expand Down Expand Up @@ -526,15 +536,19 @@ information visually through lexical scoping (as covered in the new ``locals()``
builtin documentation).

To allow extension module code to behave consistently regardless of the active
Python scope, the stable C ABI would gain the following new function::
Python scope, the stable C ABI would gain the following new function:

.. code-block:: c

PyObject * PyLocals_GetCopy();

``PyLocals_GetCopy()`` returns a new dict instance populated from the current
locals namespace. Roughly equivalent to ``dict(locals())`` in Python code, but
avoids the double-copy in the case where ``locals()`` already returns a shallow
copy. Akin to the following code, but doesn't assume there will only ever be
two kinds of locals result::
two kinds of locals result:

.. code-block:: c

locals = PyLocals_Get();
if (PyLocals_GetKind() == PyLocals_DIRECT_REFERENCE) {
Expand Down Expand Up @@ -598,7 +612,9 @@ specifics of when the namespace it returns gets refreshed are still an
interpreter implementation detail)

The additions to the public CPython C API are the frame level enhancements
needed to support the stable C API/ABI updates::
needed to support the stable C API/ABI updates:

.. code-block:: c

PyLocals_Kind PyFrame_GetLocalsKind(frame);
PyObject * PyFrame_GetLocals(frame);
Expand Down Expand Up @@ -628,7 +644,9 @@ affected code should be updated to use
instead.

In addition to the above documented interfaces, the draft reference
implementation also exposes the following undocumented interfaces::
implementation also exposes the following undocumented interfaces:

.. code-block:: c

PyTypeObject _PyFastLocalsProxy_Type;
#define _PyFastLocalsProxy_CheckExact(self) Py_IS_TYPE(op, &_PyFastLocalsProxy_Type)
Expand Down Expand Up @@ -1238,7 +1256,7 @@ complexity improvement.
The O(1) nature of the other operations can be restored by adding implementation
code that doesn't rely on the value cache being up to date.

Keeping the iterator/iterable retrieval methods as ``O(1)`` will involve
Keeping the iterator/iterable retrieval methods as O(1) will involve
writing custom replacements for the corresponding builtin dict helper types,
just as proposed in :pep:`667`. As illustrated above, the implementations would
be similar to the pseudo-code presented in :pep:`667`, but not identical (due to
Expand Down
0