PEP 531: minor updates

- fixed some formatting inconsistencies
- explain the reasoning behind ?else and ?or

pep-0531.txt

@@ -28,18 +28,18 @@ expressions and statements:
 These expressions will be defined in terms of a new "existence" protocol,
 accessible as ``operator.exists``, with the following characteristics:
 
-    * types can define a new ``__exists__`` magic method (Python) or
-      ``tp_exists`` slot (C) to override the default behaviour. This optional
-      method has the same signature and possible return values as ``__bool__``.
-    * ``operator.exists(None)`` returns ``False``
-    * ``operator.exists(NotImplemented)`` returns ``False``
-    * ``operator.exists(Ellipsis)`` returns ``False``
-    * Python's builtin and standard library numeric types will override the
-      existence check such that ``NaN`` values return ``False`` and other
-      values return ``True``
-    * for any other type, ``operator.exists(obj)`` returns True by default. Most
-      importantly, values that evaluate to False in a boolean context (zeroes,
-      empty containers) evaluate to True in an existence checking context
+* types can define a new ``__exists__`` magic method (Python) or
+  ``tp_exists`` slot (C) to override the default behaviour. This optional
+  method has the same signature and possible return values as ``__bool__``.
+* ``operator.exists(None)`` returns ``False``
+* ``operator.exists(NotImplemented)`` returns ``False``
+* ``operator.exists(Ellipsis)`` returns ``False``
+* Python's builtin and standard library numeric types will override the
+  existence check such that ``NaN`` values return ``False`` and other
+  values return ``True``
+* for any other type, ``operator.exists(obj)`` returns True by default. Most
+  importantly, values that evaluate to False in a boolean context (zeroes,
+  empty containers) evaluate to True in an existence checking context
 
 
 Relationship with other PEPs
@@ -75,9 +75,9 @@ results that depend on the missing data) rather than failing outright.
 
 Some particularly common cases where this issue arises are:
 
-- handling optional application configuration settings and function parameters
-- handling external service failures in distributed systems
-- handling data sets that include some partial records
+* handling optional application configuration settings and function parameters
+* handling external service failures in distributed systems
+* handling data sets that include some partial records
 
 It is the latter two cases that are the primary motivation for this PEP - while
 needing to deal with optional configuration settings and parameters is a design
@@ -140,7 +140,7 @@ handling idiom:
 
 * ``value = value if value is not None else expensive_default()``
 
-to instead be abbreviated as:
+allowing that to instead be abbreviated as:
 
 * ``value ?= expensive_default()``
 
@@ -193,7 +193,7 @@ we see:
 
 * The ``?[]`` existence checking attribute access syntax precisely aligns with:
 
-  * the "safe navigation" attribute access operator in C# (``?[]``)
+  * the "safe navigation" subscript operator in C# (``?[]``)
   * the "optional subscript" operator in Swift (``?[].``)
 
 * The ``?else`` existence checking fallback syntax semantically aligns with:
@@ -207,6 +207,14 @@ languages, but they're the most common ones, and the ``?`` is far and away
 the most common syntactic marker (presumably prompted by the use of ``?`` in
 C-style conditional expressions, which many of these languages also offer).
 
+``?else`` is proposed over ``?or`` for the existence checking fallback syntax
+simply because it reads more clearly as "choose the first subexpression that
+exists" when multiple instances of the expression are chained together.
+
+``?and`` is proposed as the spelling for the existence checking precondition
+syntax as it semantically relates to ``?else`` in the same way that ``and``
+relates to ``or``.
+
 
 Risks and concerns
 ==================