Add BackendRegistry singleton class #27719
Conversation
lib/matplotlib/rcsetup.py
Outdated
| 'pdf', 'pgf', 'ps', 'svg', 'template'] | ||
| all_backends = interactive_bk + non_interactive_bk | ||
| # Deprecation of module-level attributes using PEP 562 | ||
| _deprecated_interactive_bk = backendRegistry.list_builtin(BackendFilter.INTERACTIVE) |
There was a problem hiding this comment.
If we didn't deprecate these 3 attributes, this block of changes would be replaced by
interactive_bk = backendRegistry.list_builtin(BackendFilter.INTERACTIVE)
non_interactive_bk = backendRegistry.list_builtin(BackendFilter.NON_INTERACTIVE)
all_backends = backendRegistry.list_builtin()There was a problem hiding this comment.
I'll block based on #27719 (comment) though only as a note that INTERACTIVE_NON_WEB should be removed; anyone can dismiss once fixed.
c9ca79f to
ea74018
Compare
|
I've removed all of |
|
|
||
|
|
||
| # Singleton | ||
| backend_registry = BackendRegistry() |
There was a problem hiding this comment.
Now we have matplotlib.backends.registry.backend_registry, which seems a bit redundant. Would it make sense to move this to _registry.py (to keep files small), and then import into matplotlib/backends/__init__.py so we have matplotlib.backends.registry as the instance?
There was a problem hiding this comment.
I'd rather not. There is value in matching the the singleton instance name backend_registry to the class name BackendRegistry. Also the internal usage is from matplotlib.backends.registry import backend_registry, so the name is free standing. Only registry would be quite ambiguous (one could change to fully qualified usages only, but 🤷 ). And finally, the backend registry is used really rarely so that verbosity is not much of an issue.
There was a problem hiding this comment.
I lean towards the explicit and verbose approach, but maybe there is some middle ground. If I keep the files named as they are but import into matplotlib.backends.__init__ using from .registry import BackendFilter, backend_registry then the standard usage becomes
from matplotlib.backends import backend_registryrather than
from matplotlib.backends.registry import backend_registryremoving some verbosity.
This has the added advantage that you cannot import the BackendRegistry class in the same way which is good as nobody should need the class, only the singleton instance.
I have implemented this in commit 8f10a01.
|
I've also added docstrings, whats new and API changes information. |
|
Were we also going to add a way for third-party backends to registering themselves? |
|
I very much think so. 😄 From the very top:
|
🐑 I failed my reading test for the day |
Yes, this PR is getting the ducks lined up ready for the real work in my next PR. |
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
8f10a01 to
a5ae8df
Compare
|
The reduction is code coverage is due to changes I have had to make to |
This is in preparation for #27663, moving the various hardcoded backend lists and dicts to a new
BackendRegistryclass that is intended to be the single source of truth for backends. There is no functional change.There is a singleton
backend_registryinstance of theBackendRegistryclass inregistry.py. This is a similar implementation to that of the singletonrcParamsinstance of theRcParamsclass.BackendRegistryincludes the two public functions that are currently needed. There will eventually be alist_allfunction to list all backends including the built-in ones, those obtained via the"module://blah.blah"approach, and those registering themselves via entry points. The class internals will change too of course.There are still some hardcoded backend names in
_fix_ipython_backend2gui, but this will be addressed as part of the wider #27663 implementation.I have not yet added an API change note. The
backend_registrycould be considered internal to Matplotlib except that IPython will also use it, so it could be thought of as fully public, or private with an exception for IPython. Other use of built-in backend lists by downstream libraries is probably restricted to use ofrcsetup.interactive_bk,non_interactive_bkandall_backends. I have deprecated them in this PR to demonstrate that this is convoluted as they are module-level attributes that need to be deprecated using the recommendations of PEP 562. But probably I would be more inclined to keep them for the moment, until we are sure how this will all work in the end, and just pass through thebackend_registryresults.(Edited to change name of singleton instance)