[srittau]

The main changes:

• Reworked the "Syntax" section of the Final spec:
  • Define just two forms, one for each of the new terms.
  • The omitted right side syntax was folded into the "explicitly typed" syntax.
  • self.id: Final was moved to the semantics section where it fits better, since it's not a separate syntax.
• Add the terms "bare Final" and "explicitly typed Final "to the glossary.

The rest of the changes use the new terms and link to the new glossary entries.

Closes: #2356

[JelleZijlstra]

We may have to say what "bare Final" does in dataclasses. I discovered ty handles this buggily: astral-sh/ty#4766.

There are two cases:

• Bare Final with a default. The obvious interpretation is that that gives you a Final dataclass field with a literal type, which is coherent but kind of useless (you can only pass that one specific type).
• Bare Final without a default. Ty and pyrefly implement this like Final[Any], which is sort of coherent but a little surprising to me; mypy disallows it; pyright interprets Final itself as a type which is definitely buggy.

[srittau]

Oh yes, I failed to mention that: Bare Finals in dataclasses are a thing, but were not mentioned by the specs. I wanted to keep the status quo in this PR, because it's not about that. I think this should be a separate discussion.

[jorenham]

Thanks!

[carljm]

Thanks!

[srittau]

I'm not sure how the process for these more editorial changes is. Does is need sign-off from the whole council?

[davidhalter]

Since this is not a "substantive" change but rather a clarification of terminology I would argue that you can just merge it. Otherwise somebody of use would have asked you to open a post on discuss as described at https://github.com/python/typing-council#decisions

I think it's good to leave issues like this one open for a week to get enough eyes on it. But it's been open more than a week, so feel free to merge.