Repository navigation
Backport annotationlib.value_to_string #544
Description
In 3.14, I added a function to annotationlib to format type-like values, so you get e.g. int instead of <type 'int'>: https://docs.python.org/3.14/library/annotationlib.html#annotationlib.value_to_string
I think this would be useful in typing-extensions too, so let's backport it.
I don't like the name very much though, and it might look even more confusing outside of annotationlib. We can still change it in CPython too, suggestions welcome.
For reference this is what it does:
def value_to_string(value):
if isinstance(value, type):
if value.__module__ == "builtins":
return value.__qualname__
return f"{value.__module__}.{value.__qualname__}"
if value is ...:
return "..."
if isinstance(value, (types.FunctionType, types.BuiltinFunctionType)):
return value.__name__
return repr(value)
Activity
srittau commentedon Mar 20, 2025
Some suggestions:
type_namepretty_type_nameformat_type_nametype_reprhauntsaninja commentedon Mar 21, 2025
type_repris the established name for this, so I'd go with that. I think I would avoid use of "value"? (It makes more sense in PEP 649 context, but this function will get used in all kinds of places)Mizokuiam commentedon Mar 23, 2025
Been looking at this backporting issue and the name discussion. I agree that
value_to_stringisn't ideal – especially outside the originalannotationlibcontext. Plus, I've run into naming collisions with similar helper functions in the past, so picking something more specific definitely makes sense.type_reprseems like the best option to me too. It clearly conveys what the function does and as @hauntsaninja pointed out, it's already a somewhat established convention.So, I'd suggest backporting the function with the name
type_repr. Here’s a quick sketch of what the backported function could look like:Should be pretty straightforward to integrate. Let me know if anything comes up.
Add backport for `annotationlib.type_repr`
Add backport for `annotationlib.type_repr` (#641)