rewrite rationale

Author: JelleZijlstra

peps/pep-0834.rst

@@ -512,19 +512,18 @@ defaults.
 Rationale
 =========
 
-Class builders make the class-transforming nature of dataclasses, enums, and
-typing constructs visible at the start of the statement.  This is easier to
-read and teach than a decorator or base class that changes class construction
-after the reader has already parsed the statement as an ordinary class.
-
-The builder protocol deliberately reuses class-body machinery instead of
-introducing a general macro or block system.  This keeps the feature close to
-existing class semantics while still allowing builders to return non-class
-objects when appropriate.
-
-Only bare names are accepted as builders.  This keeps the syntax compact and
-avoids ambiguous statement prefixes such as ``pkg.builder C:``.  Users can
-bind a local name when they want to use a builder imported from another module.
+Python has various constructs that are somewhat like classes, but behave
+subtly (or not so subtly!) differently. This PEP proposes a generic, flexible
+mechanism for defining such constructs.
+
+An alternative could be to add specific syntax for some or all of the constructs
+for which this PEP proposes to use class builders. For example, ``protocol`` could
+be made a soft keyword, allowing protocols to be written as proposed in this PEP,
+but without an import and without a more powerful new language feature.
+
+However, this would unduly privilege the standard library. There are use
+cases in third-party frameworks that could be helped by builder syntax, including
+alternative dataclass-like frameworks, ORMs, or DSLs.
 
 
 Backwards Compatibility