Fix #4855: Blacklist rcParams that aren't style #5440

Merged
merged 6 commits into from Dec 31, 2015

Conversation

Projects
None yet
5 participants
Owner

mdboom commented Nov 8, 2015

Needs a what's new

mdboom added the needs_review label Nov 8, 2015

mdboom added this to the next major release (2.0) milestone Nov 8, 2015

@efiring efiring commented on an outdated diff Nov 8, 2015

lib/matplotlib/style/core.py
def is_style_file(filename):
"""Return True if the filename looks like a style file."""
return STYLE_FILE_PATTERN.match(filename) is not None
+def _apply_style(d):
+ mpl.rcParams.use(blacklist_style_params(d))
@efiring

efiring Nov 8, 2015

Owner

Missing a leading underscore.

@efiring efiring commented on an outdated diff Nov 8, 2015

lib/matplotlib/style/core.py
@@ -34,11 +34,27 @@
STYLE_FILE_PATTERN = re.compile('([\S]+).%s$' % STYLE_EXTENSION)
+# A list of rcParams that should not be applied from styles
+STYLE_BLACKLIST = set([
+ 'interactive', 'backend', 'backend.qt4', 'webagg.port',
+ 'webagg.port_retries', 'webagg.open_in_browser', 'backend_fallback',
+ 'toolbar', 'timezone', 'datapath', 'figure.max_open_warning',
+ 'savefig.directory', 'tk.window_focus', 'hardcopy.docstring'])
+
+
+def _blacklist_style_params(d):
@efiring

efiring Nov 8, 2015

Owner

The name is not so clear in indicating that a dict of valid params will be returned; how about _screened_style_params or _valid_style_params?

@efiring efiring commented on an outdated diff Nov 8, 2015

lib/matplotlib/style/core.py
@@ -34,11 +34,27 @@
STYLE_FILE_PATTERN = re.compile('([\S]+).%s$' % STYLE_EXTENSION)
+# A list of rcParams that should not be applied from styles
+STYLE_BLACKLIST = set([
+ 'interactive', 'backend', 'backend.qt4', 'webagg.port',
+ 'webagg.port_retries', 'webagg.open_in_browser', 'backend_fallback',
+ 'toolbar', 'timezone', 'datapath', 'figure.max_open_warning',
+ 'savefig.directory', 'tk.window_focus', 'hardcopy.docstring'])
+
+
+def _blacklist_style_params(d):
+ return dict((k, v) for (k, v) in d.items() if k not in STYLE_BLACKLIST)
@efiring

efiring Nov 8, 2015

Owner

Would it make sense to raise a warning if a a blacklisted key is found?

Owner

tacaswell commented Nov 11, 2015

Should also remove all of the black-listed entries from classic

Owner

mdboom commented Nov 12, 2015

@tacaswell: Good point about removing blacklisted entries from the classic style. Done.

Owner

mdboom commented Nov 17, 2015

I think this one is good to go.

@WeatherGod WeatherGod and 2 others commented on an outdated diff Nov 17, 2015

lib/matplotlib/style/core.py
@@ -71,18 +96,18 @@ def use(style):
for style in styles:
if not cbook.is_string_like(style):
- mpl.rcParams.update(style)
+ _apply_style(style)
continue
elif style == 'default':
mpl.rcdefaults()
@WeatherGod

WeatherGod Nov 17, 2015

Member

There is a bit of a disconnect here. rcdefaults() is more than just style stuff, but it doesn't make sense to blacklist entries there, either, does it?

@efiring

efiring Dec 30, 2015

Owner

@mdboom, I think @WeatherGod has a good point here: 'default' style should modify only non-blacklisted things, shouldn't it?

@mdboom

mdboom Dec 30, 2015

Owner

I see. That makes sense.

@WeatherGod WeatherGod commented on the diff Nov 17, 2015

lib/matplotlib/style/core.py
@@ -34,11 +35,35 @@
STYLE_FILE_PATTERN = re.compile('([\S]+).%s$' % STYLE_EXTENSION)
+# A list of rcParams that should not be applied from styles
+STYLE_BLACKLIST = set([
+ 'interactive', 'backend', 'backend.qt4', 'webagg.port',
+ 'webagg.port_retries', 'webagg.open_in_browser', 'backend_fallback',
+ 'toolbar', 'timezone', 'datapath', 'figure.max_open_warning',
+ 'savefig.directory', 'tk.window_focus', 'hardcopy.docstring'])
@WeatherGod

WeatherGod Nov 17, 2015

Member

what about the default keymappings?

@mdboom

mdboom Nov 17, 2015

Owner

In that case, I thought using style might be handy, e.g. an Emacs key style (not that one could do that given our current framework, but you get the idea).

Member

WeatherGod commented Nov 17, 2015

I think this raises a bit more general question of what is the line between styles and settings. There are tons of other settings such as the default keymappings, animation settings, and such that may or may not make sense as a "style". I am fine with what has been chosen so far, it is just a question of how much more do we want to blacklist.

Member

WeatherGod commented Nov 17, 2015

Also, do we know if people have been using style.use() as a convenient way to apply custom rcParams? If so, then this change could break that use-case (not that it would have been a good thing to do in the first place, though)

Owner

mdboom commented Nov 17, 2015

Also, do we know if people have been using style.use() as a convenient way to apply custom rcParams?

No, but I know of at least three cases where style was used to turn interactive on and caused end users no end of trouble... ;)

Member

WeatherGod commented Nov 17, 2015

This is all fine, but we still don't have a definition that can help guide us in choosing what should and shouldn't be allowed in a style file. So, to get the conversation rolling, I'll propose a definition: "a non-style parameter is one whose change would have no effect after importing pyplot". This definition might not be good enough. Should the line be drawn at figure creation? axes creation?

Owner

mdboom commented Nov 17, 2015

My definition is things that affect the appearance of the plot are style. Things that are related to the environment/platform in use and other technical considerations are not.

Owner

mdboom commented Nov 20, 2015

@tacaswell: Any thoughts on the definition of "style parameters" here?

Owner

tacaswell commented Nov 20, 2015

I would say it has to have a visual effect, rather than a ui effect (interactive, key bindings, default file types) which i think lines up with what @mdboom said and is a super set of @WeatherGod. Things like dpi are on the edge and should probably be allowed.

Owner

mdboom commented Dec 6, 2015

I've added a comment about what should be blacklisted. I hope that addresses the comments above, and otherwise this is good-to-merge.

Owner

mdboom commented Dec 29, 2015

I think this is ready-to-merge, unless there are other comments.

Owner

efiring commented Dec 30, 2015

@mdboom, see @WeatherGod's first inline comment.

@mdboom mdboom Don't apply blacklisted params from default style
d9d1671

@efiring efiring added a commit that referenced this pull request Dec 31, 2015

@efiring efiring Merge pull request #5440 from mdboom/blacklist-style-params
Fix #4855: Blacklist rcParams that aren't style
8decc8c

@efiring efiring merged commit 8decc8c into matplotlib:master Dec 31, 2015

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls First build on master at 68.492%
Details

efiring removed the needs_review label Dec 31, 2015

Owner

efiring commented Dec 31, 2015

I have the impression that some might want tighter restrictions--a larger blacklist. Merging this does not preclude such changes, but it seems worthwhile to get the mechanism in place without further delay.

Owner

jenshnielsen commented Jan 1, 2016

Should this be backported to 2.0?

Owner

mdboom commented Jan 1, 2016

yes.

@jenshnielsen jenshnielsen added a commit to jenshnielsen/matplotlib that referenced this pull request Jan 5, 2016

@efiring @jenshnielsen efiring + jenshnielsen Merge pull request #5440 from mdboom/blacklist-style-params
Fix #4855: Blacklist rcParams that aren't style
4c319fc

jenshnielsen referenced this pull request Jan 5, 2016

Merged

Backport blacklist #5796

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