Documentation preview for this PR (built with commit e7abaf6; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

Thanks for looking into the issue! The fix looks good to me except for the typo revealed by the tests.

Would you mind tests that leading_monomial() and leading_term() work correctly on multivariate polynomials, though?

Would also be useful to have test for both cases (copy=False and copy=True), as well as adding documentation what it means (ideally just point all of them to one place)

Would also be useful to have test for both cases (copy=False and copy=True), as well as adding documentation what it means (ideally just point all of them to one place)

It's not clear to me how to do this without a lot of boring work which I'd rather not do. There is not really a benefit, I think.

@fchapoton, the linter is complaining, should I fix these here or separately? Also, what is the correct invocation at home? If I do ./sage -tox -e pycodestyle-minimal -- src/sage/rings/polynomial/multi_polynomial.pyx it is selecting the wrong set of rules:

pycodestyle-minimal: commands[0] /home/martin/sage-trac/src> pycodestyle --select E111,E21,E221,E222,E225,E227,E228,E25,E271,E275,E303,E305,E306,E401,E502,E701,E702,E703,E71,E72,W291,W293,W391,W605 sage/rings/polynomial/multi_polynomial.pyx
sage/rings/polynomial/multi_polynomial.pyx:483:22: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:536:21: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:536:25: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:546:25: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:546:36: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:547:21: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:547:33: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:568:34: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:778:16: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:778:28: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:778:51: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:778:63: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:2131:19: E225 missing whitespace around operator
sage/rings/polynomial/multi_polynomial.pyx:2137:23: E225 missing whitespace around operator
14      E225 missing whitespace around operator
pycodestyle-minimal: exit 1 (0.15 seconds) /home/martin/sage-trac/src> pycodestyle --select E111,E21,E221,E222,E225,E227,E228,E25,E271,E275,E303,E305,E306,E401,E502,E701,E702,E703,E71,E72,W291,W293,W391,W605 sage/rings/polynomial/multi_polynomial.pyx pid=27666
  pycodestyle-minimal: FAIL code 1 (0.21=setup[0.07]+cmd[0.15] seconds)
  evaluation failed :( (0.37 seconds)

the linter must pass. You just need to start with r""" the block containing the new \Z

note that pyx files and py file are treated with different rules. In particular E225 is not applied to pyx files

Thinking about it…

It might be much better for the user to just deprecate the copy feature and requires copy=True everywhere. It's better for elements to be immutable anyway, and especially not by mutating an unrelated object.

But then grepping for monomial_coefficients(copy=False) in the code base, it is used in quite a lot of places as a small performance optimization. Not sure if it's worth it (we can always move copy=False to an internal implementation detail e.g. def _monomial_coefficients_nocopy() which classes can define if it has a special no-copy version)

No, we definitely should not get rid of copy input. It is a very important performance feature for sparse implementations already in that dict form. Specifically IndexedFreeModuleElement.

Alternatively, would it make sense to return an immutable dict?

(But, please, not in this PR)

Python doesn't have immutable dict. Maybe a dict view would be reasonable but that would be significant change… yes, for this PR we should not consider that issue.

Indeed Python doesn't, and sometimes we do want to modify the internal dict.

Would you mind tests that leading_monomial() and leading_term() work correctly on multivariate polynomials, though?

I did add doctests, involving different term orderings, see for example src/sage/categories/modules_with_basis.py lines 1906ff.

Is this what you had in mind, @mezzarobba ?

Yes, thank you!