Precise annotation for _field_types ClassVar

[hunterhogan]

Refine the type annotation for _field_types to a more specific union of types, enhancing type safety and clarity in the codebase.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[JelleZijlstra]

This is incorrect, _field_types doesn't hold any of those types.

[hunterhogan]

I apologize for my hubris. I'll open an issue. (peace) سلام, 和谐 (group harmony), health, and happiness, Hunter Sent from Proton Mail Android

…

-------- Original Message --------

On 6/8/25 8:01 AM, Jelle Zijlstra wrote: JelleZijlstra left a comment [(python/typeshed#14241)](#14241 (comment)) This is incorrect, _field_types doesn't hold any of those types. — Reply to this email directly, [view it on GitHub](#14241 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAWSIU77VSWISG6CV4L3KZL3CQXZVAVCNFSM6AAAAAB62TRWU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJUGA3DANJQGM). You are receiving this because you authored the thread.Message ID: ***@***.***>

[hunterhogan]

Issue created #14245

This is incorrect, _field_types doesn't hold any of those types.

"those types":

_ConstantValue | AST | list[AST] | list[str]

True, the annotation is not precise, and it may be incorrect, but _field_types certainly holds at least one of those types: list[str].

>>> ast.Global._field_types
{'names': list[str]}
>>> ast.Nonlocal._field_types
{'names': list[str]}
>>> ast.MatchClass._field_types['kwd_attrs']
list[str]

I sincerely don't know how to evaluate your claim that _field_types doesn't hold _ConstantValue. I think _ConstantValue is a "UnionType", but even if it is a "UnionType," I have not been able to decipher the implications of that. So, I don't know for sure whether or not _ConstantValue in this context is malformed syntax. I thought it was valid syntax, but your challenge that none of the four types are correct makes me think it could be malformed.

I omitted some types from the annotation because I believed they were represented by _ConstantValue. As you know, the types in _ConstantValue are str | bytes | bool | int | float | complex | None | EllipsisType. Of those, excluding ast.Constant and its subclasses:

• ✔️ str is held by _field_types,
• ❌ bytes is not held by _field_types,
• ❌ I don't know for sure that Literal[True, False] is the same as bool, so perhaps it is not held by _field_types,
• ✔️ int is held by _field_types,
• ❌ float is not held by _field_types,
• ❌ complex is not held by _field_types,
• ✔️ None is held by _field_types,
• ❌ EllipsisType or Ellipsis or ellipsis is not held by _field_types.

[JelleZijlstra]

The dictionary contains the value list[str], which is not an instance of the type list[str].

The correct annotation for this field is arguably TypeForm from the draft PEP 747, though it could be something a little narrower since the actual set of types in the ast module is a bit smaller than all possible type forms.

[hunterhogan]

The dictionary contains the value list[str], which is not an instance of the type list[str].

I did not see that coming.

I just reread the ClassVar documentation. Despite now knowing the above is true, I can't decipher the documentation.

Thank you for the explanation.

[JelleZijlstra]

This is nothing to do with ClassVar, it's how all type annotations work.

[hunterhogan]

This is nothing to do with ClassVar, it's how all type annotations work.

Hmm. I suspect I have a significant defect in my mental model of type annotations.

Oh no, I hope my mental model isn't flawed because I don't understand OOP despite 30+ years of exposure to OOP. 😨