Type hint for Plotly Express text_auto should accept str

[GustaFranz]

Description

I am seeing a false-positive type-checking error in Pylance/Pyright when I use a documented numeric format string with text_auto in Plotly Express.

This report specifically concerns plotly.express.bar (the px.bar function exposed by import plotly.express as px), whose text_auto parameter is inferred as bool by Pylance/Pyright.

The runtime behavior is correct, and the documentation states that text_auto accepts either a boolean or a string. A string such as ".2f" is interpreted as a numeric texttemplate formatting directive.

Steps to reproduce

import plotly.express as px

media_disciplina = {
    "disciplina": ["Math", "Science"],
    "media": [8.5, 7.2],
}

fig = px.bar(
    media_disciplina,
    x="disciplina",
    y="media",
    title="Average by subject",
    text_auto=".1f",
)

Pylance reports:

Argument of type "Literal['.1f']" cannot be assigned to parameter "text_auto" of type "bool" in function "bar"

Expected behavior

Static type checking should accept both bool and str for text_auto, matching the documented and runtime API.

Notes

The current function signature uses an unannotated default:

text_auto=False

Pylance/Pyright therefore infers the parameter as bool from its default value.

Could the Plotly Express functions that expose text_auto be annotated as accepting both supported values? For compatibility with older Python versions, an annotation such as the following would address this:

from typing import Union

text_auto: Union[bool, str] = False

If this is an appropriate change, I would be happy to submit a pull request.

[camdecoster]

Thanks for the report! As you mentioned, this error is from the inference that Pylance is doing. There's a long standing request to add type hints to plotly.py and we're interested in it, but it will take some dedicated time to get it done. One of our team members is interested in picking away at this, so I'll assign it to him and we'll see how far we can get. I'm going to close this issue as a duplicate of the original issue, #1103.