FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Calling savefig() changes the return value of ax.get_xticklabels() · Issue #6800 · matplotlib/matplotlib · GitHub

Repository navigation

Calling savefig() changes the return value of ax.get_xticklabels() #6800

Closed

Description

matplotlib 1.5.1 on Linux, installed from binary package, both on Python 3.5.2 and 2.7.12.

Here is the code:

import pylab
f, axes = pylab.subplots(2, sharex=True, sharey=True)
for ax in axes:
    ax.plot(range(100))
for ax in axes:
    print([x.get_text() for x in ax.get_xticklabels()])
print('----')
pylab.savefig('/tmp/tempfig.png')
for ax in axes:
    print([x.get_text() for x in ax.get_xticklabels()])

The output is:

['', '', '', '', '', '']
['', '', '', '', '', '']
----
['0', '20', '40', '60', '80', '100']
['0', '20', '40', '60', '80', '100']

If I comment out the call to savefig(), I get

['', '', '', '', '', '']
['', '', '', '', '', '']
----
['', '', '', '', '', '']
['', '', '', '', '', '']

The tick labels (which I am trying to get) are seen in the figure:

Is this expected?

Activity

  1. WeatherGod commented on Jul 19, 2016

    Member

    Yes, sort of. This is one of the warts in matplotlib's design. Several
    things are deferred until draw time. Axes ticks are one of them. There are
    similar problems with facecolors of some scalar mappables that are
    initialized to blue to start but won't get their final color until draw
    time.

    It isn't a bug, per se, but it is a wart. We really should make it so that
    calls like get_xticklabels() forces the artist to not defer any longer and
    compute their relevant values.

    On Tue, Jul 19, 2016 at 1:47 PM, Lev Levitsky notifications@github.com
    wrote:

    matplotlib 1.5.1 on Linux, installed from binary package, both on Python
    3.5.2 and 2.7.12.

    Here is the code:

    import pylab
    f, axes = pylab.subplots(2, sharex=True, sharey=True)for ax in axes:
    ax.plot(range(100))for ax in axes:
    print([x.get_text() for x in ax.get_xticklabels()])print('----')
    pylab.savefig('/tmp/tempfig.png')for ax in axes:
    print([x.get_text() for x in ax.get_xticklabels()])

    The output is:

    ['', '', '', '', '', '']

    ['', '', '', '', '', '']

    ['0', '20', '40', '60', '80', '100']
    ['0', '20', '40', '60', '80', '100']

    If I comment out the call to savefig(), I get

    ['', '', '', '', '', '']

    ['', '', '', '', '', '']

    ['', '', '', '', '', '']
    ['', '', '', '', '', '']

    The tick labels (which I am trying to get) are seen in the figure:

    [image: image]
    https://cloud.githubusercontent.com/assets/3358268/16960270/5d0b5976-4df1-11e6-89e6-a86a55b9f0eb.png

    Is this expected?

    —
    You are receiving this because you are subscribed to this thread.
    Reply to this email directly, view it on GitHub
    #6800, or mute the thread
    https://github.com/notifications/unsubscribe-auth/AARy-CyXgJx0CgthUp4DoKKaWecUEnvwks5qXQ2ygaJpZM4JP_EQ
    .

  2. story645 commented on Jul 19, 2016

    Member

    This is kinda a dupe of #6638 so wondering if at least for now it should at the least be a doc patch? (Where though...)

  3. levitsky commented on Jul 19, 2016

    Author

    This is indeed a dupe, sorry for not searching thoroughly enough. Feel free to close it as such or do whatever you think is better.
    At least I get the idea now, thank you.

  4. story645 commented on Jul 19, 2016

    Member

    It's fine! ('specially since I created the other issue...). I'm just wondering out loud about where something can be slotted in to alleviate some of this confusion.

  5. tacaswell commented on Jul 19, 2016

    Member

    A better question is why are you trying to do this?

  6. levitsky commented on Jul 19, 2016

    Author

    That's because I don't know the API so well.
    I was trying to re-set the tick labels just to change their font size.
    I have already figured out that I can use setp() for that.

  7. story645 commented on Jul 19, 2016

    Member

    @tacaswell what about a warning on the get_methods if you try and call 'em before the figure is drawn? (or is that way too much overhead...)

  8. WeatherGod commented on Jul 19, 2016

    Member

    The problem is that it is only some methods that are problematic, and I
    don't think anybody has a clear idea which ones they are.

    On Tue, Jul 19, 2016 at 3:05 PM, hannah notifications@github.com wrote:

    Oh, @tacaswell https://github.com/tacaswell what about a warning on the
    get_methods if you try and call 'em before the figure is drawn? (or is that
    way too much overhead...)

    —
    You are receiving this because you commented.
    Reply to this email directly, view it on GitHub
    #6800 (comment),
    or mute the thread
    https://github.com/notifications/unsubscribe-auth/AARy-BNrU9y43y8KYvnb5kLytF-mZkP_ks5qXR_tgaJpZM4JP_EQ
    .

  9. QuLogic commented on Dec 20, 2022

    Member

    This was fixed by #23170.

  10. added this to the v3.6.0 milestone on Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL