Feedback

Author: cdce8p

peps/pep-0823.rst

@@ -107,7 +107,7 @@ simplified example:
     @dataclass
     class Customer:
         user: User | None
-        shopping_card: list[Item]
+        shopping_cart: list[Item]
 
     @dataclass
     class User:
@@ -181,7 +181,7 @@ least for dictionaries a useful helper method is ``dict.get(key)``.
 
     class Customer(TypedDict):
         user: User | None
-        shopping_card: list[Item]
+        shopping_cart: list[Item]
 
     class User(TypedDict):
         name: str
@@ -191,15 +191,15 @@ least for dictionaries a useful helper method is ``dict.get(key)``.
         if customer is not None:
             user = customer["user"]
             if user is not None:
-                return user.name.lower()
+                return user["name"].lower()
         return None
 
 Writing it using ``?.`` and ``?[ ]`` would look like this:
 
 ::
 
     def get_customer_name(data: Data) -> str | None:
-        return data.get("customer")?["user"]?.name.lower()
+        return data.get("customer")?["user"]?["name"].lower()
 
 Other common patterns
 ---------------------
@@ -217,7 +217,7 @@ hide in plain sight. Attribute and function names have been shortened.
     falsy values, e.g. ``False``, ``""``, ``0``, ``[]``, ``{}`` or custom
     objects which overwrite ``__bool__``, are filtered out too though.
     If code relied on this property, the expression cannot necessarily
-    be replaced with ``?.`` or ``.[ ]``.
+    be replaced with ``?.`` or ``?[ ]``.
 
 ::
 
@@ -298,7 +298,7 @@ attribute or subscript access were used.
     # base?.tail
     _t.tail if ((_t := base) is not None) else None
 
-The ``base`` can be replace with any number of expressions, including
+The ``base`` can be replaced with any number of expressions, including
 `Parenthesized ones <Parenthesized expressions - groupings_>`_
 while the ``tail`` is limited to attribute access, subscript,
 their ``None``-aware variants and call expressions.
@@ -324,11 +324,12 @@ Short-circuiting
 
 If the left hand side (the ``base``) for ``?.`` or ``?[ ]`` evaluates to
 ``None``, the remaining expression (the ``tail``) is skipped and the
-result will be set to ``None`` instead. The ``AttributeError`` for
-accessing a member of ``None`` or ``TypeError`` for trying to subscribe
-to ``None`` are omitted. It is therefore not necessary to change
-subsequent ``.`` or ``[ ]`` on the right hand side just because a
-``?.`` or ``?[ ]`` is used prior.
+result will be set to ``None`` instead. This includes everything in the
+tail part, e.g. evaluating function arguments or subscripts. The
+``AttributeError`` for accessing a member of ``None`` or ``TypeError``
+for trying to get a subscript of ``None`` are omitted. It is therefore
+not necessary to change subsequent ``.`` or ``[ ]`` on the right hand
+side just because a ``?.`` or ``?[ ]`` is used prior.
 
 ::
 
@@ -384,7 +385,7 @@ in case the first part evaluates to ``None``.
     (a.b?.c or d).e?.func()
 
     # a.b?.c
-    _t2 = _t1.c if ((t1 := a.b) is not None) else None
+    _t2 = _t1.c if ((_t1 := a.b) is not None) else None
 
     # (... or d)
     _t3 = _t2 if _t2 else d
@@ -495,7 +496,7 @@ Multiline formatting
 Using two separate tokens to express ``?.`` and ``?[`` allows developers
 to insert a space or line break as needed. For multiline expressions it
 enables that ``?`` is appended to the ``optional`` subexpression whereas
-``.`` or ``[`` could be moved to the next line. This is indented merely
+``.`` or ``[`` could be moved to the next line. This is intended merely
 as an option for developers. Everyone is free to choose a style that fits
 their needs, especially code formatters might prefer a style which
 conforms better to their existing preferences. An example of what
@@ -937,20 +938,21 @@ might be too easy to miss besides "normal" attribute access and subscript
 operators.
 
 This is a valid concern. Especially for long lines, it is not difficult
-to imaging a ``?`` hiding somewhere. However, as with all proposals the
-downsides have to be weight against the alternatives. As shown in the
+to imagine a ``?`` hiding somewhere. However, as with all proposals the
+downsides have to be weighed against the alternatives. As shown in the
 `Motivation`_ section, accessing nested values from objects with
 ``optional`` attributes can be quite cumbersome. Getting all steps right,
 often involves a combination of assignment expressions, temporary
 variables and chained conditionals. Especially for beginners this can be
-overwhelming and it is frequently just faster to repeat each subexpression
-as well as only relying on the implicit ``bool(...) is True`` check instead
-of ``is not None``, which can fail in unexpected ways. It is also
-a bit slower. Even if the statements and expressions are written
-correctly, reading them again is far from simple.
+overwhelming and it is frequently just easier to repeat each subexpression
+as well as only relying on the implicit ``bool(...) is True`` check, which
+can fail in unexpected ways, instead of ``is not None``. It is also
+a bit slower since the expressions are not cached and evaluated again
+for every step. Additionally, even if the statements and expressions are
+written correctly, reading them again is far from simple.
 
 In contrast, ``?.`` and ``?[ ]`` leave the core of the expression mostly
-untouched. It is thus fairly strait forward to see what is happening.
+untouched. It is thus fairly straight forward to see what is happening.
 Furthermore, it will be easier to write since one can start from the
 normal attribute access and subscript operators and just insert ``?``
 as needed. The Python error messages for accessing a member or subscript
@@ -988,7 +990,7 @@ attributes, i.e. do ``getattr(obj, attr, None) is not None``.
 
 It was decided that the ``None``-aware operators should only handle
 ``optional`` attributes, see the `Exception-aware operators`_ section
-section for more details why the latter interpretation was rejected.
+for more details why the latter interpretation was rejected.
 
 Similar to `Easy to get ?. wrong`_ the discussion created a lot of
 confusion what the agreed upon interpretation should be. This will also
@@ -1082,13 +1084,13 @@ out for, only using keyword attributes for class patterns, making sure
 the attribute names are correct since the class pattern can also match
 ``missing`` once and as such will not emit an error if it is misspelled,
 and the performance impact from an often times unnecessary ``isinstance``
-check. Furthermore, great care must be taking during refactorings as
+check. Furthermore, great care must be taken during refactorings as
 patterns often can not be updated automatically.
 
 While the match statement has been available in Python since 3.10,
 anecdotal evidence suggests that developers still prefer other
 alternatives for ``optional`` attributes, at least for simple,
-strait-forward expression. Pattern matching starts to become much more
+straight-forward expression. Pattern matching starts to become much more
 useful once multiple attributes or values need to be checked at the
 same time.