| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
| # Values are typles of (version,) | ||
| # Values are tuples of (version,) | ||
| _deprecated_remain_as_none = { | ||
| 'axes.hold': ('2.1',), |
There was a problem hiding this comment.
(other mentions of axes.hold have already been removed)
Sorry, something went wrong.
|
I think the reason for these "remain_as_none" is so that people with style
files that can be used across multiple versions of matplotlib won't get
errors if they happen to have an entry that was recently deprecated.
…On Wed, Jul 18, 2018 at 9:22 AM, Antony Lee ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In lib/matplotlib/__init__.py
<#11692 (comment)>
:
> _deprecated_remain_as_none = {
- 'axes.hold': ('2.1',),
(other mentions of axes.hold have already been removed)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#11692 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARy-NsToeuw4eppaMusOIeTvBOjtfykks5uHzaUgaJpZM4VUlrv>
.
|
Sorry, something went wrong.
|
But one cannot actually set it to a value of None from the rcfile (https://github.com/matplotlib/matplotlib/blob/v2.2.2/lib/matplotlib/rcsetup.py#L151). So in practice, the only change removing that entry does is to replace a specific deprecation message ("axes.hold is deprecated, will be removed in 3.0") by a generic unknown-key message ("Bad key "axes.hold""). |
Sorry, something went wrong.
|
Look at that code again. If it is None, then it returns None. It doesn't go
through validate_bool().
…On Wed, Jul 18, 2018 at 10:29 AM, Antony Lee ***@***.***> wrote:
But one cannot actually set it to a value of None from the rcfile (
https://github.com/matplotlib/matplotlib/blob/v2.
2.2/lib/matplotlib/rcsetup.py#L151).
So in practice, the only change removing that entry does is to replace a
specific deprecation message ("axes.hold is deprecated, will be removed in
3.0") by a generic unknown-key message ("Bad key "axes.hold"").
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11692 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARy-DTXKMm2RNfoI1qkcmfVIa8evnWXks5uH0ZBgaJpZM4VUlrv>
.
|
Sorry, something went wrong.
|
But the rc parser will pass the string "None", not the None object. Manually adding such an entry in your rc file confirms that behavior. |
Sorry, something went wrong.
|
Hmm, you are right. Then what's the point of all of this stuff in
`__init__.py`? We have deprecation mechanisms in multiple places! It is
obvious that we were supposed to be able to suppress deprecation messages
for axes.hold in some places, but not others? That's weird.
…On Wed, Jul 18, 2018 at 10:51 AM, Antony Lee ***@***.***> wrote:
But the rc parser will pass the string "none", not the None object.
Manually adding such an entry in your rc file confirms that behavior.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11692 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARy-FledSgMNyWTIi-Hmes3eFvqDvf1ks5uH0tlgaJpZM4VUlrv>
.
|
Sorry, something went wrong.
|
One may want to restore the suppression behavior somehow (but that's a separate issue), but right now the only point is to trigger a deprecation message on get and set (and when doing rcParams["blah"] = None directly). |
Sorry, something went wrong.
|
As pointed out in #10939 I would expect there to be a way to get rid of the "frame", i.e. the figure's background patch entirely. |
Sorry, something went wrong.
|
Why does a transparent rectangle in the output file bother you? |
Sorry, something went wrong.
|
There are several reasons not wanting a background at all. Let's simply say transparency is unfortunately not handled well in every program you might use your figure with afterwards. Indeed, plt.savefig("test.png")
plt.gcf().patch.set_visible(False)
plt.savefig("test.svg")
gives the expected result. But that is somehow inconsistent. If the figure patch is the object to manipulate for the saved figure's background appearance, one would expect that to be the case in general, not only for set_visible. I.e. the following does not produce a green background, plt.gcf().set_facecolor("palegreen")
plt.savefig("test.png")
plt.savefig("test.svg")
|
Sorry, something went wrong.
|
That's because savefig overrides facecolor and that's exactly why I proposed #10023. |
Sorry, something went wrong.
|
Not sure I'm following here, but there sure are reasons to let the saved background be different from the one shown on screen, and to do this within the savefig. (Arguments are given precisely in #10023) The full API is there, it's just not implemented correctly for frameon. One could of course make that more consistent, in the sense of savefig(..., **kwargs) where **kwargs are passed on to the figure patch of the saved figure. So frameon will become visible and transparent will need to be set via facecolor=(1,1,1,0). |
Sorry, something went wrong.
|
I'd rather have the API proposed in #10023 (comment). Let's move the discussion there? |
Sorry, something went wrong.
| The following API elements are deprecated: | ||
|
|
||
| - the ``frameon`` kwarg to ``savefig`` and the ``savefig.frameon`` rcParam (use | ||
| ``facecolor`` instead), |
There was a problem hiding this comment.
Can you please be a bit more specific? What values does one have to pass to facecolor to obtain the effect of frameon=True/False.
Sorry, something went wrong.
There was a problem hiding this comment.
clarified
Sorry, something went wrong.
There was a problem hiding this comment.
Anybody can merge after CI pass.
Sorry, something went wrong.
``frameon = False`` has *never* worked since its introduction in 2013
due to the buggy implementation that only took it into account if True:
if frameon:
original_frameon = self.get_frameon()
self.set_frameon(frameon)
(despite the doc stating otherwise). One can also set the facecolor
kwarg or savefig.facecolor rcParam to fully transparent for the same
effect.
There was a problem hiding this comment.
Blocking on further discussion tomorrow on the call. I think @ImportanceOfBeingErnest has some valid points and we are going to get a lot of blowback about this.
Sorry, something went wrong.
Do you have a specific example in mind? |
Sorry, something went wrong.
|
Going to merge this, but am open to reverting if we get much push back on this after it is released. I think running this through controlling the color / transparency of the patch directly is clearer than an independent flag. |
Sorry, something went wrong.
…692-on-v3.1.x Backport PR #11692 on branch v3.1.x (Deprecate frameon kwarg and rcParam to savefig.)
| Back | FazBrowse Home | New Git URL |
frameon = False has never worked since its introduction in 2013 (#1875)
due to the buggy implementation that only took it into account if True:
if frameon: original_frameon = self.get_frameon() self.set_frameon(frameon)(despite the doc stating otherwise). One can also set the facecolor
kwarg or savefig.facecolor rcParam to fully transparent for the same
effect.
(See also #10023.)
PR Summary
PR Checklist