# Proposal: add \`@typing.format\_specifiers(...)\` **URL:** \ **Category:** Ideas\ **Tags:** typing\ **Created:** [July 7, 2026, 12:32pm UTC](https://discuss.python.org/t/proposal-add-typing-format-specifiers/108070 "2026-07-07T12:32:20Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![jonathandung](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jonathandung/32/35459_2.png) [@jonathandung](https://discuss.python.org/u/jonathandung)\ **Post date:** [July 7, 2026, 12:32pm UTC](https://discuss.python.org/t/proposal-add-typing-format-specifiers/108070/1 "2026-07-07T12:32:20Z")
This decorator factory would tell type checkers what format codes are supported by instances of that type. It would take variable positional arguments, each a string corresponding to a valid specification, and type checkers will know the class its returned decorator is applied to will only take those format specifications, so that it can flag mistyped format specifications and make subtle bugs clear. It, however, requires special-casing string formatting and the `format` builtin. Currently it is possible to restrict the type of `format_spec` in ` __format__ ` to `Literal[...]`, but that will cause Liskov substitution principle violations and type checkers may not consider it. ---
**Author:** ![jonathandung](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jonathandung/32/35459_2.png) [@jonathandung](https://discuss.python.org/u/jonathandung)\ **Post date:** [July 18, 2026, 5:45am UTC](https://discuss.python.org/t/proposal-add-typing-format-specifiers/108070/2 "2026-07-18T05:45:23Z")
[python/typing#2321](https://github.com/python/typing/issues/2321) ---
**Author:** ![dr\_carlos](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dr_carlos/32/30461_2.png) [@dr\_carlos](https://discuss.python.org/u/dr_carlos)\ **Post date:** [July 18, 2026, 11:12pm UTC](https://discuss.python.org/t/proposal-add-typing-format-specifiers/108070/3 "2026-07-18T23:12:39Z")
As much as I like the idea, adding a new decorator and new mechanism for type checkers to implement just to solve the very specific problem of knowing which formatting codes are supported by a class doesn’t really sit well with me. Makes me wonder if it’s really a type-checking problem to begin with? It seems like a question of supported values, not our set-theoretic types. ---
**Author:** ![jonathandung](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jonathandung/32/35459_2.png) [@jonathandung](https://discuss.python.org/u/jonathandung)\ **Post date:** [July 19, 2026, 12:30am UTC](https://discuss.python.org/t/proposal-add-typing-format-specifiers/108070/4 "2026-07-19T00:30:18Z")
To deduce what format codes an object supports, the type of the object has to be known. I forgot to include the context; this actually stemmed from [astral-sh/ruff#25744](https://github.com/astral-sh/ruff/issues/25744). ---
**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\ **Post date:** [July 19, 2026, 12:45am UTC](https://discuss.python.org/t/proposal-add-typing-format-specifiers/108070/5 "2026-07-19T00:45:06Z")
A decorator definitely seems like the wrong way to handle this (and other) typing features. Anything done for the benefit of static analysis should be possible to defer and not have runtime costs. type-checkers could use the signature of ` __format__ ` here, no decorator required. Any LSP issue for this is likely a typechecker issue along the lines of other issues with typecheckers not holistically incorporating the data model methods into the typechecker’s knowledge and constraints ---
**Author:** ![jonathandung](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jonathandung/32/35459_2.png) [@jonathandung](https://discuss.python.org/u/jonathandung)\ **Post date:** [July 19, 2026, 3:25am UTC](https://discuss.python.org/t/proposal-add-typing-format-specifiers/108070/6 "2026-07-19T03:25:34Z")
Agreed that this is a possibility.