Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport annotationlib.value_to_string #544

Open
JelleZijlstra opened this issue Mar 20, 2025 · 3 comments
Open

Backport annotationlib.value_to_string #544

JelleZijlstra opened this issue Mar 20, 2025 · 3 comments

Comments

@JelleZijlstra
Copy link
Member

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)
@srittau
Copy link
Collaborator

srittau commented Mar 20, 2025

Some suggestions:

  • type_name
  • pretty_type_name
  • format_type_name
  • type_repr

@hauntsaninja
Copy link
Collaborator

type_repr is 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
Copy link

Been looking at this backporting issue and the name discussion. I agree that value_to_string isn't ideal – especially outside the original annotationlib context. Plus, I've run into naming collisions with similar helper functions in the past, so picking something more specific definitely makes sense.

type_repr seems 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:

import types

def type_repr(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)

Should be pretty straightforward to integrate. Let me know if anything comes up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants