PEP 764: Updates from discussion

[Viicos]

• Remove note about readability -- it is up to the user to decide whether readability is a concern.
• Address some open issues:
  • Implicitly closed
  • Inlined TDs cannot extend, nor be extended
  • typing.Dict: same reasoning as dict
• Misc. edits

• Change is either:
  • To a Draft PEP
  • To an Accepted or Final PEP, with Steering Council approval
  • To fix an editorial issue (markup, typo, link, header, etc)
• PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

---

📚 Documentation preview 📚: https://pep-previews--4270.org.readthedocs.build/

[erictraut]

This implies an ordering dependency between the two PEPs. If this PEP is accepted prior to 728, then this would represent a breaking change if and when PEP 728 is accepted — something that will likely get significant pushback. Therefore, it's probably best for this PEP to be considered for acceptance only after (or concurrently with) PEP 728's submission.

[Viicos]

Agree, that's why I initially put this in the open issues section. I'll move it back there, and add a note that PEP 728 needs to be addressed (either accepted or rejected) before pursuing with PEP 764.

[JelleZijlstra]

I'm hoping to push PEP 728 to resolution soon.

[erictraut]

Why is extending an inlined TypedDict disallowed? I understand why we'd want to disallow extending other TypedDicts via an inlined TypedDict definition, but it's unclear why this limitation would be imposed. It seems kind of arbitrary. Perhaps there's some complication related to runtime implementation?

[Viicos]

So from a static type checking perspective, I don't think it matters really, although the usefulness is debatable. However, depending on the runtime implementation we choose to go to (either a normal TypedDict class with an arbitrary '<inlined TypedDict>' name, or an instance of a new typing._TBDClass), the runtime behavior might be difficult to implement. I'll move this in the open issues section, alongside the runtime implementation discussion.

[erictraut]

I don't think it matters really, although the usefulness is debatable

I think we should strive to make new features consistent. Regardless of how a TypedDict is defined (the class syntax, functional syntax, or inlined syntax), the resulting type should work the same. If this limitation is left in the PEP, it means that there will be two variants of TypedDict that act differently — and therefore need to be treated by static analysis tools as slightly different beasts.

[erictraut]

I agree with the text in this section, but the example code looks incorrect to me. The example shows a generic type alias declaration using the old-style (PEP 747) way of defining a type alias. In this case, the type variable T is bound to a valid scope — the type alias.

You can address this by changing the example code to use a form that will not be interpreted by a type checker as a type alias. For example, use a local variable (within a function body) or add a type annotation.

def func():
    InlinedTD = TypedDict[{"name": T}]

InlinedTD: object = TypedDict[{"name": T}]