Wrapping up

Author: Viicos

.github/CODEOWNERS

@@ -640,6 +640,7 @@ peps/pep-0759.rst  @warsaw
 peps/pep-0760.rst  @pablogsal @brettcannon
 peps/pep-0761.rst  @sethmlarson @hugovk
 peps/pep-0762.rst  @pablogsal @ambv @lysnikolaou @emilyemorehouse
+peps/pep-0764.rst  @Viicos @erictraut
 # ...
 peps/pep-0777.rst  @warsaw
 # ...

peps/pep-0764.rst

@@ -17,8 +17,8 @@ Abstract
 :pep:`589` defines a :ref:`class-based <typing:typeddict-class-based-syntax>`
 and a :ref:`functional syntax <typing:typeddict-functional-syntax>` to create
 typed dictionaries. In both scenarios, it requires defining a class or
-assigning to a value. In some situations, this can add unnecessary boilerplate,
-especially if the typed dictionary is only used once.
+assigning to a value. In some situations, this can add unnecessary
+boilerplate, especially if the typed dictionary is only used once.
 
 This PEP proposes the addition of a new inlined syntax, by subscripting the
 :class:`~typing.TypedDict` type::
@@ -93,11 +93,15 @@ The :class:`~typing.TypedDict` class is made subscriptable, and accepts a
 single type argument which must be a :class:`dict`, following the same
 semantics as the :ref:`functional syntax <typing:typeddict-functional-syntax>`
 (the dictionary keys are strings representing the field names, and values are
-valid :ref:`annotation expressions <typing:annotation-expression>`).
+valid :ref:`annotation expressions <typing:annotation-expression>`). Only the
+comma-separated list of ``key: value`` pairs within braces constructor
+(``{k: <type>}``) is allowed, and should be specified directly as the type
+argument (i.e. it is not allowed to use a variable which was previously
+assigned a :class:`dict` instance).
 
 Inlined typed dictionaries can be referred to as *anonymous*, meaning they
-don't have a name. For this reason, their :attr:`~type.__name__` attribute
-will be set to an empty string.
+don't have a name (see the `runtime behavior <Runtime behavior>`_
+section).
 
 It is possible to define a nested inlined dictionary::
 
@@ -135,8 +139,6 @@ are bound to some outer scope::
 
     InlinedTD = TypedDict[{'name': T}]  # Not OK, `T` refers to a type variable that is not bound to any scope.
 
-**TODO** closed
-
 Typing specification changes
 ----------------------------
 
@@ -158,19 +160,20 @@ implemented as a function at runtime. To be made subscriptable, it will be
 changed to be a class.
 
 Creating an inlined typed dictionary results in a new class, so ``T1`` and
-``T2`` are the same type (apart from the different :attr:`~type.__name__`)::
+``T2`` are of the same type::
 
     from typing import TypedDict
 
     T1 = TypedDict('T1', {'a': int})
     T2 = TypedDict[{'a': int}]
 
+As inlined typed dictionaries are are meant to be *anonymous*, their
+:attr:`~type.__name__` attribute will be set to an empty string.
 
 Backwards Compatibility
 =======================
 
-Apart from the :class:`~typing.TypedDict` internal implementation change, this
-PEP does not bring any backwards incompatible changes.
+This PEP does not bring any backwards incompatible changes.
 
 
 Security Implications
@@ -236,7 +239,7 @@ While this would avoid having to import :class:`~typing.TypedDict` from
 * For type checkers, :class:`dict` is a regular class with two type variables.
   Allowing :class:`dict` to be parametrized with a single type argument would
   require special casing from type checkers, as there is no way to express
-  parametrization overloads. On ther other hand, :class:`~typing.TypedDict` is
+  parametrization overloads. On the other hand, :class:`~typing.TypedDict` is
   already a :term:`special form <typing:special form>`.
 
 * If future work extends what inlined typed dictionaries can do, we don't have
@@ -277,6 +280,13 @@ Should we allow the following?::
     class SubTD(InlinedTD):
         pass
 
+What about defining an inlined typed dictionay extending another typed
+dictionary?::
+
+    InlinedBase = TypedDict[{'a': int}]
+
+    Inlined = TypedDict[InlinedBase, {'b': int}]
+
 Using ``typing.Dict`` with a single argument
 --------------------------------------------
 
@@ -285,16 +295,39 @@ While using :class:`dict` isn't ideal, we could make use of
 
     def get_movie() -> Dict[{'title': str}]: ...
 
-It is less verbose, doesn't have the baggage of :class:`dict`,
-and is defined as some kind of special form (an alias to the built-in
-``dict``).
+It is less verbose, doesn't have the baggage of :class:`dict`, and is
+already defined as some kind of special form.
 
 However, it is currently marked as deprecated (although not scheduled for
 removal), so it might be confusing to undeprecate it.
 
 This would also set a precedent on typing constructs being parametrizable
 with a different number of type arguments.
 
+Should inlined typed dictionaries be proper classes?
+----------------------------------------------------
+
+The PEP currently defines inlined typed dictionaries as type objects, to be in
+line with the existing syntaxes. To work around the fact that they don't have
+a name, their :attr:`~type.__name__` attribute is set to an empty string.
+
+This is somewhat arbitrary, and an alternative name could be used as well
+(e.g. ``'<TypedDict>'``).
+
+Alternatively, inlined typed dictionaries could be defined as instances of a
+new (internal) typing class, e.g. :class:`!typing._InlinedTypedDict`. While
+this solves the naming issue, it requires extra logic in the runtime
+implementation to provide the introspection attributes (such as
+:attr:`~typing.TypedDict.__total__`), and tools relying on runtime
+introspection would have to add proper support for this new type.
+
+Inlined typed dictionaries and extra items
+------------------------------------------
+
+:pep:`728` introduces the concept of *closed* type dictionaries. Inlined
+typed dictionaries should probably be implicitly *closed*, but it may be
+better to wait for :pep:`728` to be accepted first.
+
 
 Copyright
 =========