Skip to content

MNT: Remove dummy_threading because threading is always available #23073

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 19, 2022

Conversation

greglucas
Copy link
Contributor

PR Summary

With Python 3.7 and above, the threading module is always available.
https://docs.python.org/3.7/library/dummy_threading.html

PR Checklist

Tests and Styling

  • [N/A] Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

Documentation

  • [N/A] New features are documented, with examples if plot related.
  • [N/A] New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • [N/A] API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).
  • [N/A] Documentation is sphinx and numpydoc compliant (the docs should build without error).

With Python 3.7 and above, the threading module is always available.
@greglucas greglucas added this to the v3.6.0 milestone May 19, 2022
@tacaswell
Copy link
Member

Are we sure this will not break pyiodide?

@greglucas
Copy link
Contributor Author

Not positive, but it looks like they've removed their dummy_threading patches?
pyodide/pyodide#796
pyodide/pyodide#144 (comment)

Ping @rth for comment on whether this will break Pyodide because it looks like you did some of the threading work over in Pyodide.

@tacaswell
Copy link
Member

I also side-banded @mdboom , we are good to go here!

Merging over the OSX failures which are due to tk installation issues.

@tacaswell tacaswell merged commit 65e9204 into matplotlib:main May 19, 2022
@greglucas greglucas deleted the rm-dummy-threading branch May 19, 2022 22:14
@rth
Copy link
Contributor

rth commented May 20, 2022

For Pyodide it should be OK, since indeed lately importing threading no longer raised an ImportError there, even though threads could still not be created.

I think the only thing that could be improved is to add

try:
    timer.start()
except RuntimeError:
    pass

in the FontManager init, as otherwise starting that thread would fail in Pyodide,

>>> timer = threading.Timer(1, lambda x: print('a'))
>>> timer.start()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/lib/python3.10/threading.py", line 928, in start
    _start_new_thread(self._bootstrap, ())
RuntimeError: can't start new thread

(timer.cancel() appears to not fail even if there was an exception for starting the thread)
This would allow us to remove the following patch https://github.com/pyodide/pyodide/blob/main/packages/matplotlib/patches/fix-threading.patch. Also see related discussion in https://discuss.python.org/t/expected-behavior-for-unsupported-stdlib-modules-in-the-browser/15689

@greglucas
Copy link
Contributor Author

Would changing the warning timer to signal.alarm work with pyodide here?

I don't see a major issue with adding the try/except either, the only minor issue is that someone else will come along again next time and say it isn't necessary because the CPython docs say it should be available :)

@tacaswell
Copy link
Member

I would rather try...except than go down the signal path.

I think of this is a secondary feature (it is warning that building the font cache is going slow which if you have oodles of fonts can take a long time and look like a process hang) so if it is degraded on pyodide that is OK and we should un-break them as simply as possible on our side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants