PEP 683: Fix some typos (#2348)
This commit is contained in:
parent
7efe7fb433
commit
d54740c33b
16
pep-0683.rst
16
pep-0683.rst
|
@ -34,7 +34,7 @@ for an immortal object will be considered immutable.
|
||||||
This approach has some possible negative impact, which is explained
|
This approach has some possible negative impact, which is explained
|
||||||
below, along with mitigations. A critical requirement for this change
|
below, along with mitigations. A critical requirement for this change
|
||||||
is that the performance regression be no more than 2-3%. Anything worse
|
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
|
large. Aside from specific applications, the fundamental improvement
|
||||||
here is that now an object can be truly immutable.
|
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,
|
memory usage. Several enterprise Python users (e.g. Instagram,
|
||||||
YouTube) have taken advantage of this. However, the above
|
YouTube) have taken advantage of this. However, the above
|
||||||
refcount semantics drastically reduce the benefits and
|
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
|
Also note that "fork" isn't the only operating system mechanism
|
||||||
that uses copy-on-write semantics. Anything that uses ``mmap``
|
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.
|
files between processes.
|
||||||
|
|
||||||
|
|
||||||
|
@ -350,7 +350,7 @@ Scope of Changes
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
Object immortality is not meant to be a public feature but rather an
|
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
|
public C-API, nor any Python API. However, this does not prevent
|
||||||
us from adding (publicly accessible) private API to do things
|
us from adding (publicly accessible) private API to do things
|
||||||
like immortalize an object or tell if one is immortal.
|
like immortalize an object or tell if one is immortal.
|
||||||
|
@ -483,8 +483,8 @@ will be made immortal. That includes the following:
|
||||||
small ints)
|
small ints)
|
||||||
|
|
||||||
All such objects will be immutable. In the case of the static types,
|
All such objects will be immutable. In the case of the static types,
|
||||||
they will be effectively immutable. ``PyTypeObject`` has some mutable
|
they will only be effectively immutable. ``PyTypeObject`` has some mutable
|
||||||
start (``tp_dict`` and ``tp_subclasses``), but we can work around this
|
state (``tp_dict`` and ``tp_subclasses``), but we can work around this
|
||||||
by storing that state on ``PyInterpreterState`` instead of on the
|
by storing that state on ``PyInterpreterState`` instead of on the
|
||||||
respective static type object. Then the ``__dict__``, etc. getter
|
respective static type object. Then the ``__dict__``, etc. getter
|
||||||
will do a lookup on the current interpreter, if appropriate, instead
|
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
|
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_>`_:
|
to try to recover some of the lost `performance <Performance_>`_:
|
||||||
|
|
||||||
* at the end of runtime init, mark all objects as immortal
|
* at the end of runtime init, mark all objects as immortal
|
||||||
|
@ -594,7 +594,7 @@ Open Issues
|
||||||
References
|
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
|
Prior Art
|
||||||
---------
|
---------
|
||||||
|
|
Loading…
Reference in New Issue