support conditional fields on TypedDict/NamedTuple/Enum/dataclasses

[carljm]

We reached consensus on this a while back in this Discuss thread, but I never got around to actually making the PR.

Seems like in the meantime we accidentally implemented the strict version of the check for TypedDict in ty, but astral-sh/ruff#24702 fixes that. Happy to wait a bit to land this if other type checkers want to have conforming implementations ready, too.

[davidhalter]

Is it intentional that this is not specified for Protocol/Enums/Dataclasses? I would probably prefer this as a consistent change for all of these.

However I'm also good with this PR as a first step.

[davidhalter]

Or maybe the question should be: Why is this not defined in a more general way in the spec? Shouldn't this be what we want in all class-like scopes? Conformance tests should probably test this for different scenarios but I personally do not see a reason to add this specifically only to TypedDicts and NamedTuples.

This PR is IMO still better then the status quo.

[JelleZijlstra]

What's special about TypedDict and NamedTuple is that they're very restricted (they don't support class variables, methods, etc.). So it makes sense to enumerate only those things that are explicitly allowed.

[AlexWaygood]

they don't support class variables, methods, etc.

(NamedTuples do support methods, unlike TypedDicts)

[davidhalter]

What's special about TypedDict and NamedTuple is that they're very restricted (they don't support class variables, methods, etc.). So it makes sense to enumerate only those things that are explicitly allowed.

TypedDict is indeed very special, but Enums/Dataclasses are IMO more special than Namedtuples. Namedtuples feel mostly like normal classes that inherit from tuple. Protocols also have a lot of special cases where they don't behave like normal classes.

[carljm]

All type-checkers already agree that this works for enums, dataclasses, and protocols. NamedTuple and TypedDict are the only points of disagreement among type checkers (mypy doesn't support conditional fields for either), and TypedDict is the only case where the current spec text explicitly forbids it.

I think it's a judgment call whether to clarify all of these cases in this PR. On the one hand, there's no reason to think that bodies of enums/dataclasses/protocols/namedtuples would be excluded from the general requirement in the spec that "type checkers are expected to understand simple version and platform checks." On the other hand, mypy didn't make this assumption for NamedTuple.

After looking at each case, I think we should draw the line at Protocol. Although protocols are special in many ways, they don't have a special syntactic form for fields/members like all of the others do. I think it would be even more of a stretch to think that conditionals in a protocol body would work any differently than in a class body.

For the "field" cases, it's easy to get the impression that only the specific syntactic forms shown in examples are supported, so I think it's worth adding a conditional example to each. (I don't think it makes sense to do the spec clarification in one central location. We should avoid referencing special cases from more general parts of the spec, because it makes it easy to miss adding a new one. And if we try to frame the rule as applying to "all special forms that use class syntax" or similar, that just adds a new point of ambiguity.)

I've updated this PR to add clarification for enums and dataclasses, as well as NamedTuple and TypedDict.