diff --git a/pep-0572.rst b/pep-0572.rst
index 3f46ee9e7..b669885c7 100644
--- a/pep-0572.rst
+++ b/pep-0572.rst
@@ -301,6 +301,22 @@ This PEP recommends always putting spaces around ``:=``, similar to
 PEP 8's recommendation for ``=`` when used for assignment, whereas the
 latter disallows spaces around ``=`` used for keyword arguments.)
 
+Change to evaluation order
+--------------------------
+
+In order to have precisely defined semantics, the proposal requires
+evaluation order to be well-defined.  This is technically not a new
+requirement, as function calls may already have side effects.  Python
+already has a rule that subexpressions are generally evaluated from
+left to right.  However, assignment expressions make these side
+effects more visible, and we propose a single change to the current
+evaluation order:
+
+- In a dict comprehension ``{X: Y for ...}``, ``Y`` is currently
+  evaluated before ``X``.  We propose to change this so that ``X`` is
+  evaluated before ``Y``.  (In a dict display like ``{X: Y}}`` this is
+  already the case, and also in ``dict((X, Y) for ...)`` which should
+  clearly be equivalent to the dict comprehension.)
 
 Differences between  assignment expressions and assignment statements
 ---------------------------------------------------------------------
@@ -541,46 +557,6 @@ An example from the low-level UNIX world::
         # Child code
 
 
-Open questions and TODOs
-========================
-
-- For precise semantics, the proposal requires evaluation order to be
-  well-defined.  We're mostly good due to the rule that things
-  generally are evaluated from left to right, but there are some
-  corner cases:
-
-  1. In a dict comprehension ``{X: Y for ...}``, ``Y`` is evaluated
-     before ``X``.  This is confusing and should be swapped.  (In a
-     dict display ``{X: Y}}`` the order is already ``X`` before
-     ``Y``.)
-
-  2. It would be good to confirm definitively that in an assignment
-     statement, any subexpressions on the left hand side are
-     evaluated after the right hand side (e.g. ``a[X] = Y`` evaluates
-     ``X`` after ``Y``).  (This already seems to be the case.)
-
-  3. Also in multiple assignment statements (e.g. ``a[X] = a[Y] = Z``)
-     it would be good to confirm that ``a[X]`` is evaluated before
-     ``a[Y]``.  (This already seems to be the case.)
-
-- Should we adopt Tim Peters's proposal to make the target scope be the
-  containing scope?  It's cute, and has some useful applications, but
-  it requires a carefully formulated mouthful.  (Current answer: yes.)
-
-- Should we disallow combining keyword arguments and unparenthesized
-  assignment expressions in the same call?  (Current answer: no.)
-
-- Should we disallow ``(x := 0, y := 0)`` and ``foo(x := 0, y := 0)``,
-  requiring the fully parenthesized forms ``((x := 0), (y := 0))`` and
-  ``foo((x := 0), (y := 0))`` instead?  (Current answer: no.)
-
-- If we were to change the previous answer to yes, should we still
-  allow ``len(lines := f.readlines())``?  (I'd say yes.)
-
-- Should we disallow assignment expressions anywhere in function
-  defaults?  (Current answer: yes.)
-
-
 Rejected alternative proposals
 ==============================