iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 683: Fix some typos (#2348)

This commit is contained in:
Petr Viktorin 2022-02-21 22:46:18 +01:00 committed by GitHub
parent 7efe7fb433
commit d54740c33b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
pep-0683.rst
View File

@ -34,7 +34,7 @@ for an immortal object will be considered immutable.
This approach has some possible negative impact, which is explained
below, along with mitigations. A critical requirement for this change
is that the performance regression be no more than 2-3%. Anything worse
the performance-neutral requires that the other benefits are proportionally
than performance-neutral requires that the other benefits are proportionally
large. Aside from specific applications, the fundamental improvement
here is that now an object can be truly immutable.
@ -111,11 +111,11 @@ This can result in a large performance improvement, especially
memory usage. Several enterprise Python users (e.g. Instagram,
YouTube) have taken advantage of this. However, the above
refcount semantics drastically reduce the benefits and
has led to some sub-optimal workarounds.
have led to some sub-optimal workarounds.
Also note that "fork" isn't the only operating system mechanism
that uses copy-on-write semantics. Anything that uses ``mmap``
relies on copy-on-write, including sharing data from shared objects
relies on copy-on-write, including sharing data from shared object
files between processes.
@ -350,7 +350,7 @@ Scope of Changes
----------------
Object immortality is not meant to be a public feature but rather an
internal one. So the proposal does *not* including adding any new
internal one. So the proposal does *not* include adding any new
public C-API, nor any Python API. However, this does not prevent
us from adding (publicly accessible) private API to do things
like immortalize an object or tell if one is immortal.
@ -483,8 +483,8 @@ will be made immortal. That includes the following:
small ints)
All such objects will be immutable. In the case of the static types,
they will be effectively immutable. ``PyTypeObject`` has some mutable
start (``tp_dict`` and ``tp_subclasses``), but we can work around this
they will only be effectively immutable. ``PyTypeObject`` has some mutable
state (``tp_dict`` and ``tp_subclasses``), but we can work around this
by storing that state on ``PyInterpreterState`` instead of on the
respective static type object. Then the ``__dict__``, etc. getter
will do a lookup on the current interpreter, if appropriate, instead
@ -520,7 +520,7 @@ to the runtime state for a small number of objects.
Performance Regression Mitigation
---------------------------------
In the interest of clarify, here are some of the ways we are going
In the interest of clarity, here are some of the ways we are going
to try to recover some of the lost `performance <Performance_>`_:
* at the end of runtime init, mark all objects as immortal
@ -594,7 +594,7 @@ Open Issues
References
==========
.. _Pyston: https://mail.python.org/archives/list/python-dev@python.org/message/TPLEYDCXFQ4AMTW6F6OQFINSIFYBRFCR/
.. _Pyston: https://mail.python.org/archives/list/python-dev@python.org/message/JLHRTBJGKAENPNZURV4CIJSO6HI62BV3/
Prior Art
---------