# PEP 737 – Unify type name formatting **URL:** \ **Category:** PEPs\ **Created:** [November 29, 2023, 1:00pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872 "2023-11-29T13:00:27Z")\ **Posts on this page:** 19\ **Page:** 3
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [January 10, 2024, 1:51pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/41 "2024-01-10T13:51:08Z")
> [@encukou](#): > > But why add a shortcut for ` __name__ `, in the same PEP that recommends not using ` __name__ ` in new code? Many people asked for it in the discussions so far. ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [January 11, 2024, 11:03am UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/42 "2024-01-11T11:03:38Z")
It’s a question for them, then. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [January 11, 2024, 1:58pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/43 "2024-01-11T13:58:10Z")
> [@vstinner](#): > > Many people asked for it in the discussions so far. I tried to find references. 2018: - Serhiy Storchaka: “I think we need to handle only two cases: short and fully qualified names. (…)” [message](https://github.com/python/cpython/issues/78776#issuecomment-1093798454) - MRAB: “%T for short form, %#T for fully qualified name”. [email](https://mail.python.org/archives/list/python-dev@python.org/message/YAJB2QUQZAF7WV4NUBN2LOGE3ACY4YJV/) - Barry Warsaw: “%t (short) and %T (long) do seem like the logical choices” [email](https://mail.python.org/archives/list/python-dev@python.org/message/XXD77YTDZ23NMJC3D2RWAGMWBXWJ66H6/) 2023: - Serhiy: “If add a specialized format, we should provide options for all reasonable variants: (…)” [message](https://github.com/python/cpython/issues/111696#issuecomment-1792916948) - Serhiy: “For different kinds of names we can use the “size” modifier.” [message](https://discuss.python.org/t/enhance-type-name-formatting-when-raising-an-exception-add-t-format-in-c-and-add-type-fullyqualname/38129/2) - Petr Viktorin: “There’s also ` __module__ + ':' + __qualname__ `, separated by semicolon rather than a dot.” [message](https://discuss.python.org/t/enhance-type-name-formatting-when-raising-an-exception-add-t-format-in-c-and-add-type-fullyqualname/38129/3) ---
**Author:** ![sirosen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sirosen/32/8478_2.png) [@sirosen](https://discuss.python.org/u/sirosen)\ **Post date:** [January 13, 2024, 9:05pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/45 "2024-01-13T21:05:31Z")
I’m chiming in with a small +1 for anything which encourages the `:`-separated format as “the primary way that a type name is stringified”. I only learned about that format last year, in spite of years of using Python, when writing some code to resolve a string to a class. It’s a nicer format for that sort of resolution (since you don’t need to walk modules; I think this is well understood?), but it’s a little bit obscure right now. Proliferating that style more widely helps guide people like me who may not have otherwise seen the format. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [January 15, 2024, 5:38pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/46 "2024-01-15T17:38:31Z")
I updated the PEP ([commit](https://github.com/python/peps/commit/8cbcebf505a3d81594dc1dd85676bb2653277bfc)): - Add `N` and `#N` formats to `type. __format__ ()` (Python API). - Add `PyType_GetModuleName()` function. - Only recommend to no longer truncate type names in **new code** (leave existing code unchanged). - Add “Formats Summary” section. This version should address all post requests and have the minimum effects on the backward compatibility. > [@encukou](#): > > It seems to me that these aren’t really worth it: > > - `{type:n}` instead of `{type. __name__ }` > - `{type:q}` instead of `{type. __qualname__ }` > - `{type:m}` instead of `{type. __module__ }` Since no one else expressed their opinion about these formats, I remove these variants to only keep the “fully qualified name” formats. We can reconsider adding them later. Let’s start with the minimum. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [January 15, 2024, 5:41pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/47 "2024-01-15T17:41:03Z")
> [@vstinner](#): > > I updated the PEP ([commit](https://github.com/python/peps/commit/8cbcebf505a3d81594dc1dd85676bb2653277bfc)): I submitted PEP 737 to the Steering Council: [PEP 737 -- Unify type name formatting · Issue #227 · python/steering-council · GitHub](https://github.com/python/steering-council/issues/227) ---
**Author:** ![MegaIng](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/megaing/32/16162_2.png) [@MegaIng](https://discuss.python.org/u/MegaIng)\ **Post date:** [January 15, 2024, 5:57pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/48 "2024-01-15T17:57:38Z")
> [@vstinner](#): > > Since no one else expressed their opinion about these formats, I remove these variants to only keep the “fully qualified name” formats. We can reconsider adding them later. Let’s start with the minimum. I did voice my support for at least `:n`, but deleted my reply for unrelated reasons. ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [January 16, 2024, 2:08pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/49 "2024-01-16T14:08:41Z")
Thank you for the PEP, and for addressing all my concerns! For the record, I still think the attribute (` __fully_qualified_name__ `) is unnecessary. As far as I can see, it’d be the first attribute on [similar types](https://docs.python.org/3/library/inspect.html#types-and-members) that’s rather easily derived from the other ones (rather than being the source of truth). Typically, operations that convert the raw data in these attributes to more useful forms live as functions in `inspect` - e.g. `signature`, `getcallargs`, `unwrap`, etc. With the helper API that the PEP now specifies, the argument against a function in `inspect` loses much of its weight – you don’t need to import it. But, you don’t need to convince me. All I ask is that you think about my concerns, which you did. I’m simply summarizing my own remaining reservations, since they’re hard to find in the big thread. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [January 16, 2024, 4:57pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/50 "2024-01-16T16:57:19Z")
> [@encukou](#): > > it’d be the first attribute on [similar types](https://docs.python.org/3/library/inspect.html#types-and-members) that’s rather easily derived from the other ones (rather than being the source of truth). I’m always surprised that the `PyTypeObject.tp_name` member is used by static types to compute: - `type. __name__ ` and `PyType_GetName()` - `type. __qualname__ ` and `PyType_GetQualName()` - `type. __module__ ` and (the recently added) `_PyType_GetModuleName()` Each access/function call creates a new string object. Heap types have a more regular design, these attributes are just members of the `PyHeapTypeObject`. See also [Investigate how the PyTypeObject members can be removed from the public C API](https://github.com/python/cpython/issues/105970). ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [February 29, 2024, 6:26pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/51 "2024-02-29T18:26:50Z")
@vstinner - The 2024 Steering Council discussed [PEP 737](https://peps.python.org/pep-0737/) today, so with that hat on, I’d like to share our feedback. First of all, thank you for putting this PEP together along with the associated PR. We can see the usefulness of the C API changes proposed by the PEP and would likely accept those changes as is. We see less justification for the Python level changes. We especially question the need for ` __fully_qualified_name__ `. As a side note, we prefer ` __fullname__ ` as previously suggested in an [earlier post](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/13) although that is moot if we do not accept the Python level changes. Our question to Victor is: would you be willing to update the PEP to propose only the C API changes, deferring the Python changes to some separate, future PEP? ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [March 1, 2024, 8:07am UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/52 "2024-03-01T08:07:24Z")
I wrote that PEP to make some C extensions compatible with the limited C API. Unifying type formatting between Python and C was a secondary goal for me. I can live without it. Next week I will work on a PEP update to move aside the Python changes. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [March 6, 2024, 10:46am UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/53 "2024-03-06T10:46:28Z")
> [@barry](#): > > Our question to Victor is: would you be willing to update the PEP to propose only the C API changes, deferring the Python changes to some separate, future PEP? I prepared [PEP 737: Remove Python changes by vstinner · Pull Request #3704 · python/peps · GitHub](https://github.com/python/peps/pull/3704) to update the PEP. Would you mind to review the changes? It changes the purpose of the PEP. It’s no longer about making type name formatting consistent between Python and C. Now it’s only adding C API to format a type fully qualified name. I have a concern: in Python, I didn’t find any function which formats a “type fully qualified name” the same way than `PyType_GetFullyQualifiedName()`: omit the module if it’s equal to `"builtins"` or `" __main__"` (or if the module is not a string). In general, it’s bad to add C functions which can do things which are not (easily) doable in Python. Is the Steering Council aware of this issue and fine with it? If the SC is fine with my updated PEP, I’m also fine with it 🙂 ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [March 6, 2024, 4:24pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/54 "2024-03-06T16:24:13Z")
> [@vstinner](#): > > In general, it’s bad to add C functions which can do things which are not (easily) doable in Python. Not “in general” - we regularly add C functions that can do things that aren’t doable in Python, and there’s nothing wrong with that (provided it’s an operation that makes sense in C and doesn’t make sense in Python). However, in this case, it does seem a bit weird to not have the C API map closely to an accessible Python value. Perhaps that means that the C API should be more like the available Python operations rather than creating something new? ---
**Author:** ![thomas](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/thomas/32/5492_2.png) [@thomas](https://discuss.python.org/u/thomas)\ **Post date:** [March 12, 2024, 12:22pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/56 "2024-03-12T12:22:29Z")
> [@vstinner](#): > > I have a concern: in Python, I didn’t find any function which formats a “type fully qualified name” the same way than `PyType_GetFullyQualifiedName()`: omit the module if it’s equal to `"builtins"` or `" __main__"` (or if the module is not a string). In general, it’s bad to add C functions which can do things which are not (easily) doable in Python. > > Is the Steering Council aware of this issue and fine with it? If the SC is fine with my updated PEP, I’m also fine with it 🙂 Our main concern was with adding attributes to all types, and the added complexity of the two ways of formatting type names in the proposed `type. __format__ ` (although very much more the former than the latter). It’s not that inconvenient to format type names in Python, since it’s just a string operation. Users can use `cls. __module__ ` and `cls. __qualname__ ` to format their own types. The only real difference is in the special-casing of `builtins`, but formatting the names of types that _might_ be builtin (and where leaving off the `builtin.` matters), that’s such a rare need I don’t think it warrants adding a ` __format__ ` method. (On the other hand, it _is_ inconvenient to format type names in C, because it’s just string operations.) If there really is a desire for formatting types the exact same way the C API does it, a utility function would make more sense to me, personally, than `type. __format__ `, but I think the SC could be persuaded given some concrete use-cases. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [March 12, 2024, 12:25pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/57 "2024-03-12T12:25:58Z")
> [@thomas](#): > > If there really is a desire for formatting types the exact same way the C API does it, a utility function would make more sense to me, personally, than `type. __format__ `, but I think the SC could be persuaded given some concrete use-cases. As I wrote, I’m fine with not making Python changes, that’s why I prepared [PEP 737: Remove Python changes by vstinner · Pull Request #3704 · python/peps · GitHub](https://github.com/python/peps/pull/3704) waiting for your review/approval 😉 I mostly worked on the C API side. If tomorrow, someone comes with a strong use case, we can obviously consider extending the Python API. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [March 12, 2024, 3:04pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/58 "2024-03-12T15:04:53Z")
> [@vstinner](#): > > If tomorrow, someone comes with a strong use case, we can obviously consider extending the Python API. It’s still today 🙂 But every time I’ve wanted that kind of name formatting in Python code (debuggers, typically), I’ve already had `inspect` imported, so it would’ve been fine as a function in there. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [March 14, 2024, 11:32am UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/59 "2024-03-14T11:32:13Z")
I updated the PR to remove Python API changes: [commit](https://github.com/python/peps/commit/b69e2daa8189428eae69bb5a7722f076cd268510). I’m now waiting for the Steering Council to review the updated PEP. ---
**Author:** ![thomas](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/thomas/32/5492_2.png) [@thomas](https://discuss.python.org/u/thomas)\ **Post date:** [March 14, 2024, 1:24pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/60 "2024-03-14T13:24:33Z")
The SC has accepted the updated PEP: [PEP 737 -- Unify type name formatting · Issue #227 · python/steering-council · GitHub](https://github.com/python/steering-council/issues/227#issuecomment-1997454919) ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [March 14, 2024, 10:41pm UTC](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872/61 "2024-03-14T22:41:57Z")
Thank you very much to everybody who was involved in the scattered discussion about PEP 737, and thanks to the Steering Council for reviewing and accepting my PEP! It’s now implemented in the main branch. Let’s see how it goes 😉 [Previous page](https://discuss.python.org/t/pep-737-unify-type-name-formatting/39872.md?page=2)