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

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.

@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).

@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.

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.

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.

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.

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)

Should this fall under the color overhaul 2.0 breaking changes?

I am -0.5, am flagging it for discussion.

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.

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.

I have this issue with matplotlib 3.1.0 on python3. And you can imagine it takes quite a while until you recognize the problem is in a library which randomely decides to remove your input parameters!

There is no manipulation of sys.argv on 3.1.0.

Yes you are right probably on python2

mo@m:~/tbin$ cat test_args.py
import sys
import matplotlib.pyplot as plt

if __name__ == '__main__':
    print(sys.argv)

The result is different between python2 and python3

mo@m:~/tbin$ python2 ./test_args.py --name foo
['./test_args.py', '--name', 'foo']

mo@m:~/tbin$ python3 ./test_args.py --name foo
['./test_args.py']

and it only happens for "--name" input argument

mo@m-:~/tbin$ python3 ./test_args.py --namex foo
['./test_args.py', '--namex', 'foo']

my current versions of matplotlib:

moghimim@m:~/tbin$  python2 -c "import matplotlib;print(matplotlib.__version__)"
2.2.4
mo@m:~/tbin$  python3 -c "import matplotlib;print(matplotlib.__version__)"
3.1.0