From d54740c33ba36f40bea1e806729938616fe5dc61 Mon Sep 17 00:00:00 2001 From: Petr Viktorin Date: Mon, 21 Feb 2022 22:46:18 +0100 Subject: [PATCH] PEP 683: Fix some typos (#2348) --- pep-0683.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/pep-0683.rst b/pep-0683.rst index dbd8e8fa4..90d907a7c 100644 --- a/pep-0683.rst +++ b/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 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 `_: * 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 ---------