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.

I investigated all scipy.special ufuncs and found that 172 were not registered in quantity_helper.

Since all of these operate on dimensionless inputs and return dimensionless outputs, I grouped them by their signature (nin/nout) and added helper functions accordingly.

This PR adds complete support along with test coverage.

If maintainers prefer a smaller incremental approach, I would be happy to split this into multiple PRs.

This PR has been rebased onto the latest main, CI issues have been resolved, and commits have been squashed into a single commit. All checks are now passing and the PR should be ready for review.

The implementation systematically registers unsupported scipy.special ufuncs by grouping them according to their nin/nout signatures and mapping them to appropriate dimensionless helper functions.

Thanks! I will let units maintainer decide if this needs a What's New entry or not.

Looks like someone else proposed a completely different approach at #19442 (doc update only). 🤷‍♀️

@mhvk Thanks, this is very helpful.

You're right that not all scipy.special functions are strictly dimensionless → dimensionless.
I'll go through the function documentation and refine the classification, handling
cases like agm, cosm1, and mathieu_cem appropriately.

I'll also add a What's New entry as suggested.

I definitely prefer to actually support the scipy ufuncs! And this PR is close, since most do require dimensionless quantities -- the only unfortunate thing is that one has to go through each of them to verify that. Thanks, @luvyarana, for taking this on!

@mhvk
Based on your feedback, I’ve made the following updates:

• Revisited the ufunc classification to better reflect their behavior.
cosm1, ellipeinc, and mathieu_* now correctly handle angle Quantity inputs,
while agm preserves units like an arithmetic operation.

• Standardized all helper registration loops to use
getattr(sps, name, None) with guards, ensuring compatibility with older SciPy versions.

• Cleaned up the code by removing unclear comments and fixing minor PEP8 issues.

• Updated behavior for key cases:

1. cosm1 accepts angle inputs and returns dimensionless output
2. agm preserves units and enforces compatible inputs
3. mathieu_* accepts angle inputs and converts to degrees as required by SciPy

• Added tests for these cases — all tests and pre-commit checks pass.

(One note from verification: for mathieu_modcem/modsem, although scipy docs mention "degrees",
the functions behave as non periodic coordinate based functions. Based on numerical checks,
treating them as dimensionless is appropriate.

Similarly, for lpmv, "degree" refers to the polynomial order rather than an angle unit,
so dimensionless handling is correct.)

I’ve also added a What’s New entry for this change.

I'll look at the actual code later, but two quick replies to your longer comment now:

Standardized all helper registration loops to use
getattr(sps, name, None) with guards, ensuring compatibility with older SciPy versions.

I'd like to only use this pattern if there is an actual need. I think new functions get relatively rarely added to scipy, so checking whether a function exists should generally not be needed. It is also better to have an explicit scipy version check in that case, so we can clean up things when they are no longer needed.

(One note from verification: for mathieu_modcem/modsem, although scipy docs mention "degrees",
the functions behave as non periodic coordinate based functions. Based on numerical checks,
treating them as dimensionless is appropriate

That seems wrong. If a function expects an argument in degrees, then the point of Quantity is that if one passes in, say, arcminutes, they get properly converted.

I think new functions get relatively rarely added to scipy, so checking whether a function exists should generally not be needed. It is also better to have an explicit scipy version check in that case, so we can clean up things when they are no longer needed.

I’ve removed the getattr(..., None) guards as suggested. Just to confirm,
are we comfortable relying on the minimum supported SciPy version to
guarantee that all these ufuncs are available?

Yes, minimum scipy version is all we guarantee astropy works for; if one wants an older one, use an older astropy too...

Note that there are test failures with "oldest supported versions", so apparently there are new additions to the special functions. If there are a lot of those, I perhaps should reconsider my ideas....

Ah, I see thanks, that clarifies it.

It looks like several of the ufuncs included here are not present in the oldest supported SciPy version, which explains the failures.

Given that, I think restoring the getattr(sps, name, None) + guard pattern makes sense here to maintain compatibility across supported versions, especially since the ufunc set does vary.

I can reintroduce the guard consistently across all loops does that sound like the preferred approach?

The issue was that some ufuncs in the list (e.g., ellip*, wright_bessel, log_wright_bessel) are not present in the minimum supported SciPy version (1.13). Using bare getattr(sps, name) caused an AttributeError at import time, which prevented all scipy ufuncs from being registered.

I’ve restored the safe pattern:
getattr(sps, name, None) with an if ufunc is not None guard across all loops (and kept the hasattr check for round), so missing functions are skipped without breaking registration.

All tests and pre-commit checks are now passing.

Hi @mhvk just a quick ping on this.

I’ve addressed the earlier feedback, including restoring the guarded getattr pattern for compatibility with older SciPy versions. All tests and checks are now passing.

I do see a failure in the mpldev image comparison job (test_noncelestial_angular, RMS ~8.6). From what I can tell, this test is in wcsaxes and doesn’t use scipy.special, so it seems unrelated to the changes here possibly due to matplotlib dev rendering differences. But since the difference is relatively large, I wanted to double check whether this should be treated as an mpldev baseline issue or something I should investigate further.

Would appreciate another look when you get a chance.