sage.rings.polynomial.polynomial_ring[_constructor]: Handle missing implementation modules

[mkoeppe]

📚 Description

We modify the __init__ methods of univariate polynomial implementation classes so that they all take an implementation keyword (and pass it on to their super).
We guard the imports of implementation classes in the PolynomialRing constructor with try... except ImportError and fall back to alternative implementations unless a specific implementation was requested.

This is part of:

• Meta-ticket: Modularize sagelib into separate distributions (pip-installable packages) sagemath-... for Sage 10.x #29705

📝 Checklist

• I have made sure that the title is self-explanatory and the description concisely explains the PR.
• I have linked an issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation accordingly.

⌛ Dependencies

[github-actions]

Documentation preview for this PR is ready! 🎉
Built with commit: 58712e2

[codecov-commenter]

Codecov Report

Patch coverage: 72.26% and project coverage change: -0.02 ⚠️

Comparison is base (f449b14) 88.62% compared to head (58712e2) 88.61%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #35277      +/-   ##
===========================================
- Coverage    88.62%   88.61%   -0.02%     
===========================================
  Files         2148     2148              
  Lines       398653   398715      +62     
===========================================
+ Hits        353308   353314       +6     
- Misses       45345    45401      +56     

Impacted Files	Coverage Δ
src/sage/rings/polynomial/polynomial_ring.py	90.39% <71.85%> (-3.88%)	⬇️
...ge/rings/polynomial/polynomial_ring_constructor.py	98.23% <100.00%> (-0.02%)	⬇️

... and 25 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[mezzarobba]

We guard the imports of implementation classes in the PolynomialRing constructor with try... except ImportError and fall back to alternative implementations unless a specific implementation was requested.

Can you say a bit more about why you want to do that? I suppose it makes sense, but I am a bit concerned about PolynomialRing(ZZ) meaning different things depending on what is installed on your system. As far as I know the implementations are not perfectly interchangeable, and non-default combinations are largely untested.

Maybe we could issue a warning when the default implementation for some base ring cannot be used due to a failing import. Would that be too intrusive?

[mkoeppe]

Can you say a bit more about why you want to do that? I suppose it makes sense, but I am a bit concerned about PolynomialRing(ZZ) meaning different things depending on what is installed on your system. As far as I know the implementations are not perfectly interchangeable, and non-default combinations are largely untested.

The main purpose of the modularization is to enable users/developers to use small parts of Sage that do not depend on many external libraries.
For example, in #35095 I am preparing a distribution sagemath-polyhedra, which uses polynomials only in a very basic way that doesn't need a specific implementation. These distributions also run doctests; currently a subset of the normal doctests is run (using the # optional annotations), but additional tests can be added for more test coverage.

Maybe we could issue a warning when the default implementation for some base ring cannot be used due to a failing import. Would that be too intrusive?

I don't think we need a run-time warning. The existing doctests already make sure that in a full installation of Sage, everything is in order.

[mezzarobba]

Ok, thanks. I suppose we can add warnings later if it does prove too confusing.

[mkoeppe]

Thank you!