TYP: Fix class annotations using names shadowed by a class member - #30754
Conversation
jorenham
left a comment
jorenham
left a comment
There was a problem hiding this comment.
Looks good, thanks.
But could you add a quick inline comment next to the py_* imports so that we don't remove it again in the future?
|
CI is failing because the pyright type-completeness dropped for some reason. So there is something in this PR that causes pyright to not be able to completely determine the type of a commonly used thing, such as dtype or ndarray. |
I am not familiar with pyright's type completeness. Do you know if it can tell what symbols are the root cause of the problem? |
I took a look, and it turns out that it's caused by the lack of generic type arguments passed to |
|
Made |
|
Thanks @hamdanal |
NumPy gh-30754 fixed annotations shadowed by class members under Python 3.14 annotation-scope rules. Later ndarray and MaskedArray signatures reintroduced bare dtype references, which ty resolves to the dtype property and consequently infers Unknown for operations such as argmax(keepdims=True). Use _dtype or np.dtype for the 53 affected annotations and bounds, and move the _dtype alias below the dtype definition. This restores precise ty inference without changing runtime behavior. A follow-up could add ty alongside Pyrefly in the type-checking workflow and check the 166 production .pyi files. With the small existing baseline of final-class, override, parameter-default, and type-argument diagnostics suppressed, invalid-type-form can remain enabled and would catch regressions like this. Follow-up to gh-30754.
NumPy gh-30754 fixed annotations shadowed by class members under Python 3.14 annotation-scope rules. Later ndarray and MaskedArray signatures reintroduced bare dtype references, which ty resolves to the dtype property and consequently infers Unknown for operations such as argmax(keepdims=True). Use _dtype or np.dtype for the 53 affected annotations and bounds, and move the _dtype alias below the dtype definition. This restores precise ty inference without changing runtime behavior. A follow-up could add ty alongside Pyrefly in the type-checking workflow and check the 166 production .pyi files. With the small existing baseline of final-class, override, parameter-default, and type-argument diagnostics suppressed, invalid-type-form can remain enabled and would catch regressions like this. Follow-up to gh-30754.
2 participants
Fixes #30752