Skip to content

TYP: Avoid shadowed dtype annotations - #31951

Merged
jorenham merged 1 commit into
numpy:mainfrom
jelle-openai:jelle/codex/fix-shadowed-dtype-annotations
Jul 10, 2026
Merged

TYP: Avoid shadowed dtype annotations#31951
jorenham merged 1 commit into
numpy:mainfrom
jelle-openai:jelle/codex/fix-shadowed-dtype-annotations

Conversation

@jelle-openai

Copy link
Copy Markdown
Contributor

PR summary

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 the ty type checker resolves to
the dtype property. As a result, it 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. If a maintainer agrees
that running ty in CI is valuable, I can work on this as a followup.

Follow-up to gh-30754.

First time committer introduction

This is @JelleZijlstra's work account. I have made many contributions to the Python ecosystem though as far as I recall I have not contributed to numpy before. See below for how I came to make this contribution.

AI Disclosure

I was having Codex look for cases where ty inferred less precise types than other type checkers. When it found some issues related to numpy, I had it prepare a fix inside numpy. I personally reviewed all code changes and wrote the final version of the PR body.

NumPy numpygh-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 numpygh-30754.

@jorenham jorenham left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Jelle!

Personally I think we should support as many type checkers as we reasonably can. I've been using ty in scipy-stubs for a while now, and even though there are still things it doesn't support (e.g. variadic type parameters), it has been smooth sailing so far. So as far as I'm concerned I'm all for adding ty as a CI job (as long as it doesn't require too many workarounds, that is).

Comment thread numpy/__init__.pyi
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants