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

Importing pyplot messes with command line argument parsing #1986

Closed
Nikratio opened this Issue May 8, 2013 · 11 comments

Comments

Projects
None yet
5 participants
@Nikratio

Nikratio commented May 8, 2013

Consider this:

[0] nelarikon:~/tmp$ cat argparsebug.py
#!/usr/bin/env python

from __future__ import division, print_function, absolute_import
from argparse import ArgumentParser
import matplotlib
import matplotlib.pyplot as plt

parser = ArgumentParser()

parser.add_argument("--name", type=str, default=None,
                    help="Prefix for files to load")

options = parser.parse_args()
print('Name is %s' % repr(options.name))
print('matplotlib version:', matplotlib.__version__)
[0] nelarikon:~/tmp$ ./argparsebug.py --name foo
Name is None
matplotlib version: 1.2.0

Removing the import matplotlib.pyplot as plt line gives the correct output,

[0] nelarikon:~/tmp$ ./argparsebug.py --name foo
Name is 'foo'
matplotlib version: 1.2.0
@mdboom

This comment has been minimized.

Show comment
Hide comment
@mdboom

mdboom May 8, 2013

Member

The general recommendation is to parse all of your commandline arguments before importing matplotlib.

Member

mdboom commented May 8, 2013

The general recommendation is to parse all of your commandline arguments before importing matplotlib.

@WeatherGod

This comment has been minimized.

Show comment
Hide comment
@WeatherGod

WeatherGod May 8, 2013

Member

That would be news to me, and I think quite unintuitive and impractical as
some may not even realize they are importing matplotlib in the first place
(as a dependency to some other library). This is something that has
bothered me and I have made some strides to reduce the impact of
matplotlib's debugging flags.

Personally, I think we ought to embrace the logging framework and abolish
command-line handling altogether in mpl.

Member

WeatherGod commented May 8, 2013

That would be news to me, and I think quite unintuitive and impractical as
some may not even realize they are importing matplotlib in the first place
(as a dependency to some other library). This is something that has
bothered me and I have made some strides to reduce the impact of
matplotlib's debugging flags.

Personally, I think we ought to embrace the logging framework and abolish
command-line handling altogether in mpl.

@mdboom

This comment has been minimized.

Show comment
Hide comment
@mdboom

mdboom May 8, 2013

Member

@WeatherGod: Sure, as a long term plan, we should reduce the commandline handling. Note, however, it isn't just for logging that mpl uses commandline flags. It also can be used to set the backend (which I personally use all the time).

Member

mdboom commented May 8, 2013

@WeatherGod: Sure, as a long term plan, we should reduce the commandline handling. Note, however, it isn't just for logging that mpl uses commandline flags. It also can be used to set the backend (which I personally use all the time).

@Nikratio

This comment has been minimized.

Show comment
Hide comment
@Nikratio

Nikratio May 8, 2013

@mdboom: Would it be possible to put that recommendation somewhere prominently? I've never heard of it before, and I couldn't find it in e.g. http://matplotlib.org/users/pyplot_tutorial.html either.

Nikratio commented May 8, 2013

@mdboom: Would it be possible to put that recommendation somewhere prominently? I've never heard of it before, and I couldn't find it in e.g. http://matplotlib.org/users/pyplot_tutorial.html either.

@mdboom

This comment has been minimized.

Show comment
Hide comment
@mdboom

mdboom May 8, 2013

Member

Yeah -- there isn't even a good place that documents what the commandline arguments are (it's sort of touched on in the FAQ).

I'm all for adding more info about this -- I'm not sure the pyplot tutorial is the right place. This is more about embedding matplotlib within a larger application.

Member

mdboom commented May 8, 2013

Yeah -- there isn't even a good place that documents what the commandline arguments are (it's sort of touched on in the FAQ).

I'm all for adding more info about this -- I'm not sure the pyplot tutorial is the right place. This is more about embedding matplotlib within a larger application.

@WeatherGod

This comment has been minimized.

Show comment
Hide comment
@WeatherGod

WeatherGod May 8, 2013

Member

I would argue that even controlling the backend selection should be done by
the script-maker. It is possible that we could make a function that makes
supplies an argparse argument to add that triggers a callback to setting
the backend, but I don't think matplotlib as a library should ever be
messing around with command line arguments.

I might be able to prototype such a argument.

Member

WeatherGod commented May 8, 2013

I would argue that even controlling the backend selection should be done by
the script-maker. It is possible that we could make a function that makes
supplies an argparse argument to add that triggers a callback to setting
the backend, but I don't think matplotlib as a library should ever be
messing around with command line arguments.

I might be able to prototype such a argument.

@efiring

This comment has been minimized.

Show comment
Hide comment
@efiring

efiring May 8, 2013

Member

On 2013/05/08 8:03 AM, Benjamin Root wrote:

I don't think matplotlib as a library should ever be
messing around with command line arguments.

I agree. Although it can be convenient, it seems like fundamentally bad
behavior. It is also obscure--which perhaps has the advantage now that
removing this behavior might be less painful than would be the case if
it had been better publicized and therefore more widely used.

Member

efiring commented May 8, 2013

On 2013/05/08 8:03 AM, Benjamin Root wrote:

I don't think matplotlib as a library should ever be
messing around with command line arguments.

I agree. Although it can be convenient, it seems like fundamentally bad
behavior. It is also obscure--which perhaps has the advantage now that
removing this behavior might be less painful than would be the case if
it had been better publicized and therefore more widely used.

@WeatherGod

This comment has been minimized.

Show comment
Hide comment
@WeatherGod

WeatherGod May 14, 2013

Member

Ok, here is a quick go at it:

import argparse

class BackendSwitcher(argparse.Action):
    """
    Set an instance of this class as an "action" to
    an argparse argument to enable backend switching.
    """
    def __call__(self, parser, namespace, values, option_string=None) :
        setattr(namespace, self.dest, values)
        matplotlib.use(values, warn=False, force=True)
Member

WeatherGod commented May 14, 2013

Ok, here is a quick go at it:

import argparse

class BackendSwitcher(argparse.Action):
    """
    Set an instance of this class as an "action" to
    an argparse argument to enable backend switching.
    """
    def __call__(self, parser, namespace, values, option_string=None) :
        setattr(namespace, self.dest, values)
        matplotlib.use(values, warn=False, force=True)

@tacaswell tacaswell modified the milestones: v1.4.x, v1.4.0 Mar 24, 2014

@tacaswell tacaswell added the doc label Sep 5, 2014

@tacaswell tacaswell modified the milestones: v1.4.x, 1.5.0 Feb 7, 2015

@tacaswell tacaswell modified the milestones: Color overhaul, next point release Jul 17, 2015

@tacaswell

This comment has been minimized.

Show comment
Hide comment
@tacaswell

tacaswell Jul 17, 2015

Member

Should this fall under the color overhaul 2.0 breaking changes?

I am -0.5, am flagging it for discussion.

Member

tacaswell commented Jul 17, 2015

Should this fall under the color overhaul 2.0 breaking changes?

I am -0.5, am flagging it for discussion.

@efiring

This comment has been minimized.

Show comment
Hide comment
@efiring

efiring Jul 17, 2015

Member

It seems like this needs to go through a deprecation cycle, unfortunately. Maybe the thing to do right away is add some documentation, including a warning that it will go away.

Member

efiring commented Jul 17, 2015

It seems like this needs to go through a deprecation cycle, unfortunately. Maybe the thing to do right away is add some documentation, including a warning that it will go away.

@mdboom mdboom modified the milestones: Color overhaul, next major release (2.0) Oct 8, 2015

@efiring

This comment has been minimized.

Show comment
Hide comment
@efiring

efiring Feb 15, 2016

Member

This can no longer be reproduced, even on mpl 1.3.1, based on testing by @tacaswell. Evidently it was fixed some time in the misty past.

Member

efiring commented Feb 15, 2016

This can no longer be reproduced, even on mpl 1.3.1, based on testing by @tacaswell. Evidently it was fixed some time in the misty past.

@efiring efiring closed this Feb 15, 2016

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