-
-
Notifications
You must be signed in to change notification settings - Fork 18.5k
PLOT: Add option to specify the plotting backend #26753
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
Changes from 1 commit
776e82d
7d89c5e
fd36e1a
3ae0662
57f0119
06e829c
f5233f3
f7c6e33
1095344
e832985
b13a74b
001c57b
231094e
aa27d34
f31fc67
1f4e1c0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,4 @@ | ||
import importlib | ||
from typing import List, Type # noqa | ||
|
||
from pandas.util._decorators import Appender | ||
|
@@ -625,11 +626,43 @@ def _get_plot_backend(): | |
The backend is imported lazily, as matplotlib is a soft dependency, and | ||
pandas can be used without it being installed. | ||
""" | ||
try: | ||
import pandas.plotting._matplotlib as plot_backend | ||
except ImportError: | ||
raise ImportError("matplotlib is required for plotting.") | ||
return plot_backend | ||
backend_str = pandas.get_option('plotting.backend') | ||
TomAugspurger marked this conversation as resolved.
Show resolved
Hide resolved
|
||
if backend_str == 'matplotlib': | ||
try: | ||
import pandas.plotting._matplotlib as backend_mod | ||
except ImportError: | ||
raise ImportError('matplotlib is required for plotting when the ' | ||
'default backend is selected.') | ||
else: | ||
try: | ||
mod = importlib.import_module(backend_str) | ||
except ImportError: | ||
raise ValueError('"{}" does not seem to be an installed module.' | ||
'A pandas plotting backend must be a module that ' | ||
'can be imported'.format(backend_str)) | ||
|
||
required_objs = ['LinePlot', 'BarPlot', 'BarhPlot', 'HistPlot', | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems like we’re being too opinionated about the backends implementation. IMO, we should provide a series and frame .plot accessor that dispatches to the right backend. We can provide an ABC for backends to subclass with the expected user API, but beyond that I don’t think we care. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't have a strong opinion about this at this point. I opened #26747 to have a discussion on what we expect from backends, this can surely be simplified. At this stage I just tried to be conservative, and force the backends to raise But happy raise exceptions from our side for some of those when the backend is not the default one, if that's the preferred option. |
||
'BoxPlot', 'KdePlot', 'AreaPlot', 'PiePlot', | ||
'ScatterPlot', 'HexBinPlot', 'hist_series', | ||
'hist_frame', 'boxplot', 'boxplot_frame', | ||
'boxplot_frame_groupby', 'tsplot', 'table', | ||
'andrews_curves', 'autocorrelation_plot', | ||
'bootstrap_plot', 'lag_plot', 'parallel_coordinates', | ||
'radviz', 'scatter_matrix', 'register', 'deregister'] | ||
missing_objs = set(required_objs) - set(dir(mod)) | ||
if len(missing_objs) == len(required_objs): | ||
raise ValueError( | ||
'"{}" does not seem to be a valid backend. Valid backends are ' | ||
'modules that implement the next objects:\n{}'.format( | ||
backend_str, '\n-'.join(required_objs))) | ||
elif missing_objs: | ||
raise ValueError( | ||
'"{}" does not seem to be a complete backend. Valid backends ' | ||
'must implement the next objects:\n{}'.format( | ||
backend_str, '\n-'.join(missing_objs))) | ||
else: | ||
backend_mod = importlib.import_module(backend_str) | ||
return backend_mod | ||
|
||
|
||
def _plot_classes(): | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question: If I wanted to use the altar backend, I would be more like to use
.set_option('plotting.backend', 'altair')
than..., 'pdvega')
. @jakevdp what name would you prefer?I think hvplot will just be hvplot, so that's fine.
Anyway, we might consider adding a dict here like
plotting_backend_alias
that maps the user-facing name likealtair
to the backend name likepdvega
. When the backend library registers themselves, they can also register their aliases.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point, and I think it'd add value to the users, but not sure if I'm in favor of adding the extra complexity it's needed to manage aliases in a dynamic way.
I like the simplicity of the parameter being the name of the module. I guess in some cases will look nicer than others. May be
hvplot
will usehvplot.pandas
, since hvplot contains other things besides our plugin, and the module to use may behvplot.pandas
.In practice I guess backends will register themselves, and users will rarely switch backends manually. But I guess if they do, it'll be better if they know they need to use the name of the module:
I don't have a strong opinion, but I'd say let's start with the simplest option, and add aliases or something else if we think it's useful once we start using this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it especially complex? I was thinking something like
Indeed, I think this simplifies things already, since we can use
'matplotlib'
aspandas.plotting._matplotlib
. Though we may continue to special case matplotlib to provide a nice error message.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I wouldn't do is to have the aliases in pandas itself. May be I'm being too strict, but if feels wrong.
But you're right, it's probably not as complex as I was thinking anyway. An simple option
plotting.aliases
with a dictionary may not be ideal, but would allow backends create an alias by simply:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but better in a follow up PR I think, so we can focus there on the exact syntax and approach
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfectly fine doing as a followup.
And my thinking may have been a bit muddled here. I was thinking that the backend library would have already been imported, and so would have a chance to register their own aliases. But as you say, it would be pandas managing them, which doesn't feel quite right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another simple option is that backends add an optional attribute
alias = 'hvplot'
, and we simply do:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes good idea. But still leaving this as a followup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I prefer to keep the focus, the smaller the PRs, the better the content :)