apply some of the review comments from Simon and Steve

iritkatriel · Oct 20, 2023 · cbaa0a3 · cbaa0a3
1 parent c4747a1
commit cbaa0a3
Showing 1 changed file with 9 additions and 6 deletions.
diff --git a/peps/pep-0733.rst b/peps/pep-0733.rst
@@ -229,7 +229,8 @@ They need to:
 * Dynamically create objects which are static in traditional
   C extensions (e.g. classes/modules), and need CPython to manage
   their state and lifetime.
-* Adapt foreign objects (strings, GC'd containers), with low overhead.
+* Dynamically adapt foreign objects (strings, GC'd containers), with
+  low overhead.
 * Adapt external mechanisms, execution models and guarantees to the
   Python way (green threads/continuations, one-writer-or-multiple-readers
   semantics, virtual multiple inheritance, 1-based indexing, super-long
@@ -284,13 +285,15 @@ design or implementation remains with us indefinitely.
 
 We can take two views on this issue. One is that this is a problem and the
 solution needs to be baked into any new C API we design, in the form of a
-process for incremental API evolution. The other possible approach is that
-this is not a problem to be solved, but rather a feature of any API. In this
+process for incremental API evolution, which includes deprecation and
+removal of API elements. The other possible approach is that this is not
+a problem to be solved, but rather a feature of any API. In this
 view, API evolution should not be incremental, but rather through large
 redesigns, each of which learns from the mistakes of the past and is not
-shackled by backwards compatibility requirements. A compromise approach
-is somewhere between these two extremes, fixing issues which are easy
-or important enough to tackle incrementally, and leaving others alone.
+shackled by backwards compatibility requirements (in the meantime, new
+API elements may be added, but nothing can ever be removed). A compromise
+approach is somewhere between these two extremes, fixing issues which are
+easy or important enough to tackle incrementally, and leaving others alone.
 
 The problem we have in CPython is that we don't have an agreed, official
 approach to API evolution. Different members of the core team are pulling in