Skip to content
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

Jump to bottom

PEP 683: Fix some typos #2348

Merged
merged 1 commit into from
Feb 21, 2022
Merged

PEP 683: Fix some typos #2348

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
16 changes: 8 additions & 8 deletions pep-0683.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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.


Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
---------
Expand Down