Hmm, one edge case that isn't currently covered in the tests is call-basedTypedDicts. I'm not sure if this behaviour is correct:

>>>from typingimport TypedDict>>>classFoo(TypedDict):......>>> Foo2= TypedDict("Foo2", {})>>> Foo.__orig_bases__(<function TypedDict at 0x000002796B986410>,)>>> Foo2.__orig_bases__()

Here's the current behaviour with call-basedNamedTuples, which is the closest stdlib analogue:

>>>from typingimport NamedTuple>>>classBar(NamedTuple):......>>> Bar2= NamedTuple("Bar2", {})>>> Bar.__orig_bases__(<function NamedTuple at 0x000002796B986200>,)>>> Bar2.__orig_bases__Traceback (most recent call last):  File "<stdin>", line 1, in <module>AttributeError: type object 'Bar2' has no attribute '__orig_bases__'

We could match the behaviour ofNamedTuple here (adding__orig_bases__ only for class-basedTypedDicts -- which Ithink is probably the correct thing to do?) by applying this diff to your PR branch:

diff --git a/Lib/typing.py b/Lib/typing.pyindex 8408edc49a..660e89cb30 100644--- a/Lib/typing.py+++ b/Lib/typing.py@@ -3107,7 +3107,9 @@ class body be required.         # Setting correct module is necessary to make typed dict classes pickleable.         ns['__module__'] = module-    return _TypedDictMeta(typename, (), ns, total=total)+    td = _TypedDictMeta(typename, (), ns, total=total)+    del td.__orig_bases__+    return td _TypedDict = type.__new__(_TypedDictMeta, 'TypedDict', (), {}) TypedDict.__mro_entries__ = lambda bases: (_TypedDict,)

I'm happy to do that, but I think the new behavior is better. Even better would be if the call approaches matched the class-based approaches, but certainly the attribute always existing is better than it only existing sometimes, right?

I think the conclusion from the in-person discussion was that we should make it return(TypedDict,) for call-based TypedDicts, right?

I think the conclusion from the in-person discussion was that we should make it return(TypedDict,) for call-based TypedDicts, right?

Yes, that sounds good. But we should fix it for call-basedNamedTuples as well, so that it's consistent between call-based NamedTuples and call-based TypedDicts. (That could be done in a separate PR, but I also wouldn't mind doing it in the same PR.)

Yup that’s what I recall as well.

Alex you did bring up the point about inline TypedDicts (which is being discussed in the mailing list and it seems like has a good chance of moving to a PEP), and how it might not make sense to have TypedDict in the bases for inline TypedDicts. Philosophically, I agree with that. But in practice, for the things that are going to be digging into the bases of a TypedDict, it is not a problem to have or not have TypedDict itself in the bases. So I think we should move forward with this keeping it as is to minimize changes and deal with inline TypedDicts if/when they show up since even if they behave different it wouldn’t really be a huge deal (and we can probably just get them to behave the same if we want to).

Alex you did bring up the point about inline TypedDicts

I think@hauntsaninja brought up the point about inline TypedDicts, but I agree with your conclusion here!

I don't know exactly how inline TypedDicts will work (for one, they won't have a name); that'll be up to Nikita to specify in the PEP. But yeah, we can discuss that when the time comes to actually implement it.

Okay, applying this patch to your PR branch appears to make call-basedTypedDicts andNamedTuples consistent with class-basedTypedDicts andNamedTuples when it comes to__orig_bases__:

diff --git a/Lib/typing.py b/Lib/typing.pyindex 8408edc49a..354bc80eb3 100644--- a/Lib/typing.py+++ b/Lib/typing.py@@ -2962,7 +2962,9 @@ class Employee(NamedTuple):     elif kwargs:         raise TypeError("Either list of fields or keywords"                         " can be provided to NamedTuple, not both")-    return _make_nmtuple(typename, fields, module=_caller())+    nt = _make_nmtuple(typename, fields, module=_caller())+    nt.__orig_bases__ = (NamedTuple,)+    return nt _NamedTuple = type.__new__(NamedTupleMeta, 'NamedTuple', (), {})@@ -3107,7 +3109,9 @@ class body be required.         # Setting correct module is necessary to make typed dict classes pickleable.         ns['__module__'] = module-    return _TypedDictMeta(typename, (), ns, total=total)+    td = _TypedDictMeta(typename, (), ns, total=total)+    td.__orig_bases__ = (TypedDict,)+    return td _TypedDict = type.__new__(_TypedDictMeta, 'TypedDict', (), {}) TypedDict.__mro_entries__ = lambda bases: (_TypedDict,)

(Needs tests as well)

Okay, applying this patch to your PR branch appears to make call-basedTypedDicts andNamedTuples consistent with class-basedTypedDicts andNamedTuples when it comes to__orig_bases__:

This, uh, would introduce a discrepancy between call-basedcollections.namedtuple and call-basedtyping.NamedTuple:

>>>import collectionsas c, typingas t>>>classFoo(c.namedtuple('Foo', {})):......>>>classBar(t.NamedTuple('Bar', {})):......>>> Foo.__orig_bases__Traceback (most recent call last):  File "<stdin>", line 1, in <module>AttributeError: type object 'Foo' has no attribute '__orig_bases__'>>> Bar.__orig_bases__(<function NamedTuple at 0x000001426A124730>,)

But I think we can live with that...

I added tests for call-based TypedDict and various NamedTuple scenarios in 631d428, your patch works great, thank you. I previously pushed 7224ddd but then remembered thatNamedTuple inheritance is not really a thing.

But I think we can live with that...

I agree, especially given that (1) it can probably be fixed there as well and (2) I think we all agree that the new behavior is better.