diff --git a/pep-0674.rst b/pep-0674.rst
index 0613bdc6075..05ff2ccef7f 100644
--- a/pep-0674.rst
+++ b/pep-0674.rst
@@ -80,24 +80,21 @@ HPy project
 
 The `HPy project <https://hpyproject.org/>`_ is a brand new C API for
 Python using only handles and function calls: handles are opaque,
-structure members cannot be accessed directly,and pointers cannot be
+structure members cannot be accessed directly, and pointers cannot be
 dereferenced.
 
-Disallowing the usage of macros as l-value helps the migration of
-existing C extensions to HPy by reducing differences between the C API
-and the HPy API.
+Searching and replacing ``Py_SET_SIZE()`` is easier and safer than
+searching and replacing some strange macro uses of ``Py_SIZE()``.
+``Py_SIZE()`` can be semi-mechanically replaced by ``HPy_Length()``,
+whereas seeing ``Py_SET_SIZE()`` would immediately make clear that the
+code needs bigger changes in order to be ported to HPy (for example by
+using ``HPyTupleBuilder`` or ``HPyListBuilder``).
 
-PyPy cpyext module
-------------------
-
-In PyPy, when a Python object is accessed by the Python C API, the PyPy
-``cpyext`` module has to convert PyPy object to a CPython object. While
-PyPy objects are designed to be efficient with the PyPy JIT compiler,
-CPython objects are less efficient and increase the memory usage.
+The fewer internal details exposed via macros, the easier it will be for
+HPy to provide direct equivalents. Any macro that references
+"non-public" interfaces effectively exposes those interfaces publicly.
 
-This PEP alone is not enough to get rid of the CPython objects in the
-PyPy ``cpyext`` module, but it is a step towards this long term goal.
-PyPy already supports HPy which is a better solution in the long term.
+These statements are endorsed by Antonio Cuni (HPy developer).
 
 
 Specification
@@ -292,8 +289,8 @@ API documentation. The majority of developers are only using CPython and
 so are not aware of compatibility issues with other Python
 implementations.
 
-Moreover, continuing to allow using macros as l-value does not solve
-issues of the nogil, PyPy and HPy projects.
+Moreover, continuing to allow using macros as l-value does not help the
+HPy project.
 
 
 Macros already modified