Make it possible for reveal_type() to format types in the same way as error messages
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 20.6k
- Forks
- 3.3k
- PR merge metrics
- PR metrics pending
Description
Feature
Add an option to reveal_type() to format the type in the same way as error messages. Something like reveal_type(variable, format="short") or similar API.
Pitch
Example (based on a bug in numpy 2.2):
import numpy as np
from numpy.typing import NDArray
def multiply(image: NDArray[np.float64], factor: float) -> NDArray[np.float64]:
reveal_type(image * factor)
return image * factor
results in
test.py:7: note: Revealed type is "numpy.ndarray[builtins.tuple[builtins.int, ...], numpy.dtype[numpy.floating[Any]]]"
test.py:8: error: Incompatible return value type (got "ndarray[tuple[int, ...], dtype[floating[Any]]]", expected "ndarray[tuple[int, ...], dtype[float64]]") [return-value]
The error is a numpy bug, and not the point of this request. My point is that the type formatting in reveal_type() is different than in the error message, which makes debugging harder. Compare
numpy.ndarray[builtins.tuple[builtins.int, ...], numpy.dtype[numpy.floating[Any]]]
ndarray[tuple[int, ...], dtype[floating[Any]]]
I would like to be able to get reveal_type() to display the type in the same way. Form a quick look, it seems that the error message uses format_type_distinctly() whereas reveal_type() uses the str representation. I assume the this is done intentionally and we don't want to change this by default (if that's not the case, could we just change it?). Therefore. I propose to make this configurable through an optional parameter.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how reveal_type() currently uses the string representation and compare it with format_type_distinctly(), which the issue identifies as the error-message formatter. Determine the optional API behavior and verify that the new format produces error-style type output while preserving the existing default behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100