✅

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

Your release notes are in good order.

Here is what the release notes will look like:

• core

  • Singleton classes with the same name that are defined twice now properly re-register on the S object. (#15163 by @asmeurer)

• printing

  • Keyword arguments to the dotprint function no longer affect consecutive calls. (#15163 by @asmeurer)

This will be added to https://github.com/sympy/sympy/wiki/Release-Notes-for-1.2.1.

Note: This comment will be updated with the latest check if you edit the pull request. You need to reload the page to see it.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->
If you run the test or doctests multiple times in the same process, you get some failures. See #15149. 
To reproduce the errors, run
```
from sympy import *
test(subprocess=False)
test(subprocess=False)
doctest(subprocess=False)
doctest(subprocess=False)
```
Unfortunately, we can't really test this on CI, as it would require running all the tests twice. Plus we split the tests up and some failures are cross-failures (e.g., doctest failures that come from running the tests).
I intend to push as many fixes here as I can, but feel free to review at any time. 
#### 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://github.com/blog/1506-closing-issues-via-pull-requests .-->
Address many issues in #15149, but not all of them yet.
#### Brief description of what is fixed or changed
#### Other comments
#### Release Notes
<!-- Write the release notes for this release below. See
https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more information
on how to write release notes. If there is no release notes entry for this PR,
write "NO ENTRY". The bot will check your release notes automatically to see
if they are formatted correctly. -->
<!-- BEGIN RELEASE NOTES -->
* printing
  * Keyword arguments to the `dotprint` function no longer affect consecutive calls.
* core
  * Singleton classes with the same name that are defined twice now properly re-register on the `S` object.
<!-- END RELEASE NOTES -->

Update

The release notes on the wiki have been updated.

Thanks! Regarding travis testing: couldn't you set the PYTHONHASHSEED outside of python? Or alternatively just always run in a subprocess (even if PYTHONHASHSEED is set). The second one only if it is a simple doctest failure and not revealing any real issues of course.

There's no functional difference between setting it outside of Python and setting it in Python. The only difference is if we set it outside of Python, we have to do it in a shell language. Also doing it that way would make it not enabled by default (e.g., when users run the tests on their own machines).

Actually, so far these have been revealing real bugs, which could also occur when using these functions multiple times in the same session. For instance, the dotprint failure was due to mutating a global value that should have been function local.

I just mean setting it outside of python on the travis build to test the behaviour.

Well the only difference is that the tests don't run in a subprocess, which can also be done with ./bin/test --no-subprocess or test(subprocess=False). But the only difference that makes is when it is run alongside something else in the same session, if the tests are modifying some global state. Actually it's kind of nice that test() does run in a subprocess by default because it means any such bugs don't affect any end users who might run the tests from within a Python session.

Yes but running it without subprocesses on travis may help catch those bugs.

We would have to run the tests twice. Just running them once and nothing else with subprocess=False is no different from running them with subprocess=True. Unfortunately, we already have too many Travis builds (the full test suite is split into 5 builds for each Python version), so we don't have the resources to run tests like this. We'll just have to occasionally do it manually.

Alright I thought running it without subprocesses would always expose more bugs. But now thinking about it I realized that it may also hide bugs where the tests rely on some global state so I guess you can't have your cake and eat it too.