Lots more tweaks

Author: msullivan

pep.rst

@@ -673,7 +673,12 @@ Object creation
   specified by ``Member`` arguments
 
 * ``NewProtocolWithBases[Bases: tuple[type], *Ms: Member]`` - A variant that
-  allows specifying bases too. TODO: Is this something we actually want?
+  allows specifying bases too. The idea is that a type would satisfy
+  this protocol if it extends all of the given bases and has the
+  specified members. (TODO: Is this something we actually
+  want? It would would be a potentially powerful feature for dealing
+  with things like Pydantic models, but protocol-with-bases would be
+  something of a new concept.)
 
 * ``NewTypedDict[*Ps: Member]`` - Creates a new ``TypedDict`` with
   items specified by the ``Member`` arguments. TODO: Do we want a way
@@ -886,13 +891,14 @@ Runtime evaluation support
 --------------------------
 
 An important goal is supporting runtime evaluation of these computed
-types.  We do not propose to add an official evaluator to the standard
+types.  We **do not** propose to add an official evaluator to the standard
 library, but intend to release a third-party evaluator library.
 
 While most of the extensions to the type system are "inert" type
-operator applications, the syntax also includes list iteration and
-conditionals, which will be automatically evaluated when the
-``__annotate__`` method of a class, alias, or function is called.
+operator applications, the syntax also includes list iteration,
+conditionals, and attribute access, which will be automatically
+evaluated when the ``__annotate__`` method of a class, alias, or
+function is called.
 
 In order to allow an evaluator library to trigger type evaluation in
 those cases, we add a new hook to ``typing``:
@@ -1149,6 +1155,10 @@ I am proposing a fully new extended callable syntax because:
     closely mimic the ``mypy_extensions`` version though, if something new
     is a non starter)
 
+TODO: Currently I made the qualifiers be short strings, for code brevity
+when using them, but an alternate approach would be to mirror
+``inspect.Signature`` more directly, and have an enum with names like
+``ParamKind.POSITIONAL_OR_KEYWORD``.
 
 .. _generic-callable-rationale:
 
@@ -1226,6 +1236,9 @@ like mapped types are unmentioned in current documentation
 Reference Implementation
 ========================
 
+There is a demo of a runtime evaluator [#runtime]_, which is
+also where this PEP draft currently lives.
+
 There is an in-progress proof-of-concept implementation in mypy [#ref-impl]_.
 
 It can type check the ORM and FastAPI-style model derivation
@@ -1234,8 +1247,6 @@ examples.
 It is missing support for callables, ``UpdateClass``, annotation
 processing, and various smaller things.
 
-There is a demo of a runtime evaluator as well [#runtime]_.
-
 Alternate syntax ideas
 ======================
 
@@ -1374,15 +1385,48 @@ Rejected Ideas
 Renounce all cares of runtime evaluation
 ----------------------------------------
 
-This would have a lot of simplifying features.
+This would give us more flexibility to experiment with syntactic
+forms, and would allow us to dispense with some ugliness such as
+requiring ``typing.Iter`` in unpacked comprehension types and having a
+limited set of ``<type-bool>`` expressions that can appear in
+conditional types.
 
-TODO: Expand
+For better or worse, though, runtime use of type annotations is
+widespread, and one of our motivating examples (automatically deriving
+FastAPI CRUD models) depends on it.
 
 Support TypeScript style pattern matching in subtype checking
 -------------------------------------------------------------
 
-This would almost certainly only be possible if we also decide not to
-care about runtime evaluation, as above.
+In TypeScript, conditional types are formed like::
+
+    SomeType extends OtherType ? TrueType : FalseType
+
+What's more, the right hand side of the check allows binding type
+variables based on pattern matching, using the ``infer`` keyword, like
+this example that extracts the element type of an array::
+
+    type ArrayArg<T> = T extends [infer El] ? El : never;
+
+This is a very elegant mechanism, especially in the way that it
+eliminates the need for ``typing.GetArg`` and its subtle ``Base``
+parameter.
+
+Unfortunately it seems very difficult to shoehorn into Python's
+existing syntax in any sort of satisfactory way, especially because of
+the subtle binding structure.
+
+Perhaps the most plausible variant would be something like::
+
+    type ArrayArg[T] = El if IsAssignable[T, list[Infer[El]]] else Never
+
+Then, if we wanted to evaluate it at runtime, we'd need to do
+something gnarly involving a custom ``globals`` environment that
+catches the unbound ``Infer`` arguments.
+
+Additionally, without major syntactic changes (using type operators
+instead of ternary), we wouldn't be able to match TypeScript's
+behavior of lifting the conditional over unions.
 
 
 Replace ``IsAssignable`` with something weaker than "assignable to" checking
@@ -1410,6 +1454,34 @@ that is similar to but not the same as subtyping, and that would need
 to either have a long and weird name like ``IsAssignableSimilar`` or a
 misleading short one like ``IsAssignable``.
 
+
+Don't use dot notation to access ``Member`` components
+------------------------------------------------------
+
+Earlier versions of this PEP draft omitted the ability to write
+``m.name`` and similar on ``Member`` and ``Param`` components, and
+instead relied on helper operators such as ``typing.GetName`` (that
+could be implemented under the hood using ``typing.GetArg`` or
+``typing.GetMemberType``).
+
+The potential advantage here is reducing the number of new constructs
+being added to the type language, and avoiding needing to either
+introduce a new general mechanism for associated types or having a
+special-case for ``Member``.
+
+``PropsOnly`` (from :ref:`the query builder example <qb-impl>`) would
+look like::
+
+    type PropsOnly[T] = typing.NewProtocol[
+        *[
+            typing.Member[typing.GetName[p], PointerArg[typing.GetType[p]]]
+            for p in typing.Iter[typing.Attrs[T]]
+            if typing.IsAssignable[typing.GetType[p], Property]
+        ]
+    ]
+
+Everyone hated how this looked a lot.
+
 .. _less_syntax:
 
 
@@ -1430,8 +1502,9 @@ Boolean operations would likewise become operators (``Not``, ``And``,
 etc).
 
 The advantage of this is that constructing a type annotation never
-needs to do non-trivial computation, and thus we don't need
-:ref:`runtime hooks <rt-support>` to support evaluating them.
+needs to do non-trivial computation (assuming we also get rid of dot
+notation), and thus we don't need :ref:`runtime hooks <rt-support>` to
+support evaluating them.
 
 It would also mean that it would be much easier to extract the raw
 type annotation.  (The lambda form would still be somewhat fiddly.
@@ -1448,35 +1521,6 @@ worse. Supporting filtering while mapping would make it even more bad
 
 We can explore other options too if needed.
 
-
-Don't use dot notation to access ``Member`` components
-------------------------------------------------------
-
-Earlier versions of this PEP draft omitted the ability to write
-``m.name`` and similar on ``Member`` and ``Param`` components, and
-instead relied on helper operators such as ``typing.GetName`` (that
-could be implemented under the hood using ``typing.GetArg`` or
-``typing.GetMemberType``).
-
-The potential advantage here is reducing the number of new constructs
-being added to the type language, and avoiding needing to either
-introduce a new general mechanism for associated types or having a
-special-case for ``Member``.
-
-``PropsOnly`` (from :ref:`the query builder example <qb-impl>`) would
-look like::
-
-    type PropsOnly[T] = typing.NewProtocol[
-        *[
-            typing.Member[typing.GetName[p], PointerArg[typing.GetType[p]]]
-            for p in typing.Iter[typing.Attrs[T]]
-            if typing.IsAssignable[typing.GetType[p], Property]
-        ]
-    ]
-
-Everyone hated how this looked a lot.
-
-
 Perform type manipulations with normal Python functions
 -------------------------------------------------------
 
@@ -1559,7 +1603,7 @@ arguments invariantly.
 Acknowledgements
 ================
 
-Jukka Lehtosalo
+Jukka Lehtosalo, etc
 
 [Thank anyone who has helped with the PEP.]