-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Deprecate the backend.qt{4,5} rcParams. #10282
Conversation
1) For the rcParams rewrite (MEP32), they may make it tricky to transform rcParams into a nested dictionary type of object, as "backend" is already the name of another (more important) rcParam. This specific issue could be solved with deprecation + renaming, but also... 2) The use of these rcParams can easily be replaced by a) first importing one of the bindings (qt_compat will ensure that the already imported binding gets used, as importing multiple bindings in the same process is a bad idea anyways), or b) setting the QT_API environment variable appropriately.
0efd32d
to
188a4af
Compare
So, is an alternative to make new rcParams that do the same thing? I don't use these rcParams, but maybe some people do. I'm not sure about the goal here other than an rcParams namespace issue? |
Renaming would be the other option, but again I think QT_API or preimporting either module is good enough. Of course, we'll see how much pushback we get after releasing this... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine w/ this, but maybe there is a large audience who uses these rcParams...
OK, maybe I made a mistake approving this. On master, with no matplotlibrc file (i.e. using the defaults), I get both these deprecation warnings, which is super annoying. I think somehow if the user does not specify these parameters, they should not still get a warning! |
For the rcParams rewrite (MEP32), they may make it tricky to
transform rcParams into a nested dictionary type of object, as "backend"
is already the name of another (more important) rcParam.
(I haven't decided on a nested dict design yet, just keeping options open.)
This specific issue could be solved with deprecation + renaming, but also...
The use of these rcParams can easily be replaced by a) first
importing one of the bindings (qt_compat will ensure that the already
imported binding gets used, as importing multiple bindings in the same
process is a bad idea anyways), or b) setting the QT_API environment
variable appropriately.
Milestoning as 2.2 so that the rcparams may actually get removed when (if) MEP32 makes it in 3.0, but feel free to push back too.
PR Summary
PR Checklist