be more specific when raising "not a constant polynomial" #37747
Conversation
|
doctest failure because one more test needs updating in: src/doc/en/thematic_tutorials/coercion_and_categories |
|
Thank you! |
|
Bit of bikeshedding, but I think |
I actually put the polynomial last on purpose: it may be a long string. I thought that in this case the error message will likely be easier to read if the polynomial comes last, because any linebreak will break the polynomial and not the |
|
I would argue the error message at the end is easier to read since it won’t be buried in a long string output (which further has the traceback above it). The double colon use in the full output is also a bit weird to me. Well, as I said, not a big deal, just wanted to mention it. |
|
OK |
|
I included another unspecific error message in the same spirit. |
|
Documentation preview for this PR (built with commit 1430492; changes) is ready! 🎉 |
|
Should we be concerned about performance implications if this ends up being called within the coercion framework on polynomials with many terms? |
|
I don’t think we need to, but it wouldn’t hurt to make it a lazy string. |
|
I am willign to do this, but on the condition of showing an example (even if artificial) where the performance degrades. (I would then turn that example as a doctest.) |
|
I don't have such tests at hand, so let's just merge it. |
|
fails as in the CI |
…omial"
Currently, if retracting a polynomial to its base ring fails, the error
message is `TypeError: not a constant polynomial`.
In some circumstances, this is not very helpful, because it may be hard
to find out where the nonconstant polynomial comes from. In particular,
this happens when the lazy implicit equations solver (sagemath#37033) fails.
Therefore, it seems sensible to add the offending polynomial.
URL: sagemath#37747
Reported by: Martin Rubey
Reviewer(s): Matthias Köppe
Currently, if retracting a polynomial to its base ring fails, the error message is
TypeError: not a constant polynomial.In some circumstances, this is not very helpful, because it may be hard to find out where the nonconstant polynomial comes from. In particular, this happens when the lazy implicit equations solver (#37033) fails.
Therefore, it seems sensible to add the offending polynomial.