printing/pretty: Do not compute parenthesization twice

[eric-wieser]

Previously both PrettyPrinter._print_Mul and prettyForm.__mul__ tried to apply parenthesis, and the action of the former hid a typo in the latter.

References to other Issues or PRs

Fixes #21814

#21844 (comment) draws attention to some weird code.

Brief description of what is fixed or changed

The arg variable was assigned but not used. The intention was probably to use args in its place, but the code reads better with args below replaced with arg instead.

This bug had no effect, because the broken code was duplicated without the bug somewhere else.

Other comments

Release Notes

NO ENTRY

[sympy-bot]

✅

Hi, I am the SymPy bot (v162). I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

• No release notes entry will be added for this pull request.

Click here to see the pull request description that was parsed.

Previously both `PrettyPrinter._print_Mul` and `prettyForm.__mul__` tried to apply parenthesis, and the action of the former hid a typo in the latter.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->

Fixes #21814

https://github.com/sympy/sympy/pull/21844#discussion_r724864850 draws attention to some weird code.

#### Brief description of what is fixed or changed

The `arg` variable was assigned but not used. The intention was probably to use `args` in its place, but the code reads better with `args` below replaced with `arg` instead.

This bug had no effect, because the broken code was duplicated without the bug somewhere else.

#### Other comments


#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
NO ENTRY
<!-- END RELEASE NOTES -->

[github-actions]

Benchmark results from GitHub Actions

Lower numbers are good, higher numbers are bad. A ratio less than 1
means a speed up and greater than 1 means a slowdown. Green lines
beginning with + are slowdowns (the PR is slower then master or
master is slower than the previous release). Red lines beginning
with - are speedups.

Significantly changed benchmark results (PR vs master)

Significantly changed benchmark results (master vs previous release)

Full benchmark results can be found as artifacts in GitHub Actions
(click on checks at the top of the PR).

[smichr]

I'm not sure it's a good idea to have two operators next to each other even though semantically the result is the same, hence, also, x**(-2).

[eric-wieser]

What do you mean "semantically the result is the same"? The same as what? (1*-)1 is nonsense, so there's only one possible interpretation of how to parse this in the first place.

[oscargus]

You are correct that there is only one possible interpretation, but I am quite sure there will be new issues opened about not have brackets around -1...

What happens with, e.g., Add(0, -1, evaluate=False)?

(In general, I think that it is a great PR, removing unnecessary code.)

[eric-wieser]

This doesn't touch the code for Add; but I assume your point is that if Add uses parens here, mul should too?

[smichr]

By semantics I mean only that the parentheses are redundant but to see two operators next to each other -- though legal, semantically -- is odd (e.g. the valid 1--2 == 3)

[oscargus]

Anyone object to merging this? Again, it may not be the end of issues related to unevaluated multiplications, but it is a step in the right direction and will also make later changes easier as the code quality improves.

I can fix the merge conflict if you prefer @eric-wieser , but I'll give you a few days to sort it out if you prefer and anyone to object against merging.