Visitar URL original
TYP: add type stub for the scalar_inv_efuncs Cython module by nstarman · Pull Request #20565 · astropy/astropy · GitHub
Skip to content

TYP: add type stub for the scalar_inv_efuncs Cython module - #20565

Open
nstarman wants to merge 1 commit into
astropy:mainfrom
nstarman:typing/scalar-inv-efuncs-stub
Open

nstarman wants to merge 1 commit into
astropy:mainfrom
nstarman:typing/scalar-inv-efuncs-stub

Conversation

@nstarman

@nstarman nstarman commented Oct 7, 2026

Copy link
Copy Markdown
Member

Adds a type stub for the scalar_inv_efuncs Cython module, so that Mypy can
see the signatures of the inverse-efunc functions that the FLRW cosmology
classes call. There are 30 public functions; the stub was generated from the
.pyx signatures (double -> float, int -> int, list -> list[float]).
list is deliberately not widened to Sequence, because the Cython argument
is declared as list and rejects tuples and arrays at runtime.

The stub was checked with stubtest against the compiled module, and it is
included in a non-editable install built from this commit. The only stubtest
message is for the Cython-generated __test__ attribute, which I did not stub.

The pyproject.toml comment saying that the module "has no stubs for Mypy to
read" is no longer true, so this also drops it.

This does not change what CI checks, since astropy.cosmology._src is still
excluded from Mypy. It is groundwork for type-checking _src one submodule per
PR, following #20556. Once flrw/* is checked, the stub makes Mypy report about
20 [assignment] errors: each subclass assigns functions with different
signatures to one variable in if/elif branches. Those will be fixed with a
Callable[..., float] annotation in the follow-up PRs, not here.

AI Disclosure

🤖 Generated with Claude Code

I am using the superpowers/brainstorming agent skill to plan a sequence of atomic PRs to fully type annotate astropy/cosmology/_src, with select small PRs to astropy/units as needed.
A Claude Opus 5.5 planned the PR sequence. A Sonnet 5.5 is in charge of orchestration, selecting which model is required for each PR. This PR was a Sonnet 5.5.

  • I certify that I am human and that I take full responsibility for this pull request including all interactions with reviewers.

Describe the 30 public functions of `scalar_inv_efuncs.pyx` so that Mypy can
check the code that calls them. The stub was generated from the Cython
signatures (`double` -> `float`, `int` -> `int`, `list` -> `list[float]`)
and checked with `stubtest` against the compiled module (apart from the
Cython-generated `__test__`, which is not stubbed).

The comment in the Mypy configuration that said the module has no stubs
is therefore no longer accurate and is dropped.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 7, 2026

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

  • Do the proposed changes actually accomplish desired goals?
  • Do the proposed changes follow the Astropy coding guidelines?
  • Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
  • Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
  • Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
  • Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
  • Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
  • Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
  • At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

@nstarman
nstarman marked this pull request as ready for review October 7, 2026 15:45
@nstarman
nstarman requested review from a team and neutrinoceros as code owners October 7, 2026 15:45
@nstarman
nstarman requested a review from taldcroft October 7, 2026 16:09
@taldcroft
taldcroft removed their request for review October 8, 2026 10:26

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

1 participant