This seems like a major API change? We either need replacements/backcompat shims or a very clear API change note for the classes that no longer exist.

Does this put a floor on our tornado support to versions that know howto play nice with asyncio?

I guess we could keep the timertornado class around? And do a lazy import of tornado if one uses it.

This way the PR would just be about adding a new timer class that doesn't need tornado, and that ipympl could use.

I don't know enough about the ecosystem (whether the jupyter side or the async side :-)) to have an answer here, but do you think anyone is actually relying on the tornado timer? Could it be reasonably deprecated? Or perhaps more mildly, moved to backend_webagg, and make backend_webagg_core a "you need to provide your own timer" abstract backend?

Given the comments and concerns about backward compatibility, I've put back theTimerTornado.

Having theTimerTornado around is harmless in a "pyodide" context like JupyterLite as long as tornado is imported lazily, so we can definitely keep it.

is there still hope on this for 3.5.0 ?

@stonebig It looks like there are still a few back-compatibility changes that need to be addressed.

We have not "feature frozen" for 3.5 yet, can you give me a sense of how important / impactful getting this in would be?

For a windows user, Tornado is non-performant.
Martin writes this is also a stone to remove to improve wasm / web flight envelop of python Jupyter stack.

So my interest to push this, as I believe it will have positive effects for python on web and python on windows. Nothing more.

This PR is affected by a re-writing of our history to remove a large number of accidentally committed filessee discourse for details.

To recover this PR it will need be rebased onto the new default branch (main). There are several ways to accomplish this, but we recommend (assuming that you call the matplotlib/matplotlib remote"upstream"

git remote updategit checkout maingit merge --ff-only upstream/maingit checkout YOUR_BRANCHgit rebase --onto=main upstream/old_master# git rebase -i main # if you prefergit push --force-with-lease# assuming you are tracking your branch

If you do not feel comfortable doing this or need any help please reach out to any of the Matplotlib developers. We can either help you with the process or do it for you.

Thank you for your contributions to Matplotlib and sorry for the inconvenience.

I’m packaging matplotlib for ArchLinux and I have some questions regarding this changes:

• the documentation (nor tests env, etc.) wasn’t updated and still says tornado is required for the webagg backend, is that correct?
• if it’s not, in what cases is tornado still required?

It is still needed, because the webagg backend provides aTornadoTimer class that might be used by dependencies (and by other places in Matplotlib?)

But in the long term the dependency might be removed?

Please someone correct me if I am wrong.

The important change here is thatbackend_webagg_core no longer requires tornado. This is the module thatipympl imports and hence hiding the tornado import at that level removes an implicit tornado dependency from ipympl.

Howeverbackend_webagg.py still very much depends ontornado, the core application class is

We may want to rename this asbackend_webagg_tornado and add abackend_webagg_fastapi,backend_webagg_aiohttp, (or maybe make those one ones sibling projects in mpl and also eject the tornado one?).