Handling Django's get_FOO_display() with Pylance

Your issue with Pylance flagging Django's dynamically generated get_FOO_display() methods is a common challenge when working with type checkers and Django's dynamic nature.

Improved Helper Function

Your current helper function has a small issue - the method name should be get_field_name_display(), not field_name_display(). Here's an improved version:

PYTHONCopied
def get_display(instance, field_name: str) -> str:
    """Get the human-readable display value for a field with choices."""
    method_name = f"get_{field_name}_display"
    method = getattr(instance, method_name)
    return method()

Type Hinting Solutions

There are a few approaches to handle this situation:

1. Using Type Ignores

You can add a type ignore comment for specific lines:

PYTHONCopied
# For a specific line
instance.get_shirt_size_display()  # type: ignore

2. Creating Type Stubs

For a more comprehensive solution, you could create type stubs for your models:

PYTHONCopied
# In a .pyi file for your model
class Person:
    def get_shirt_size_display(self) -> str: ...

3. Using Protocol Classes

For a more generic approach, you could define a protocol:

PYTHONCopied
from typing import Protocol, TypeVar

T = TypeVar('T')

class ModelWithChoices(Protocol):
    def __getattr__(self, name: str) -> object: ...

def get_display(instance: ModelWithChoices, field_name: str) -> str:
    """Get the human-readable display value for a field with choices."""
    method_name = f"get_{field_name}_display"
    method = getattr(instance, method_name)
    return method()

4. Using Django-Stubs with Pylance

While you mentioned you're not using django-stubs with Pylance for speed reasons, it's worth noting that django-stubs does provide type definitions for these dynamic methods. If performance is an issue, you might consider using it selectively or configuring Pylance to reduce its analysis scope.

Overriding Field.contribute_to_class()

As mentioned in the Django documentation, for more complex cases you might need to override Field.contribute_to_class() to customize how these methods are added, but this is typically only necessary for advanced customization scenarios and wouldn't directly solve your typing issue.

The simplest approach is likely using the improved helper function with appropriate type annotations, combined with selective type ignores where needed.