Move future.pyplot out of future and import it by default

[Federico M Pouzols]

The main point here is to do as the title of the ticket says. In principle the module would stay as pyplot. This comes with some additional / side issues that are being described in this small document: ​https://github.com/mantidproject/documents/blob/master/Design/Plotting/plotting_namespaces_conventions.md

I think/hope there are no issues with this, but as several changes to the user interface are required, please give your thoughts.

Bonus:

• Add a table that says which traditional mantidplot plots are supported in mantidplot.pyplot and which ones are not. There was a list/table in ​https://github.com/mantidproject/documents/blob/master/Design/Plotting/plotting_cli.md. This could go relatively early in the module documentation, before or after "Plot a Mantid workspace".

• As for the plotting tool names (plot_spectrum vs. spectrum): support both. List the options available in a table.

[Martyn Gigg]

For clarification: do we actually just want to bring all of the commands into the standard MantidPlot namespace, i.e. a user would type

plot(...)

and get our new plot command. There seems little point in just moving pyplot out of future and not doing this as users will still have to know to type from pyplot import *

[Federico M Pouzols]

I was thinking to do an import pyplot or an import as, to keep everything inside a pyplot, plt or similar namespace. So yes users would need to do pyplot.plot() pyplot.title() etc. or do an additional import. I guess I tend to like prefixes to know where functions come from (numpy goes to np., pyplot goes to plt., etc.), like they do in the pyplot tutorial: ​http://matplotlib.org/users/pyplot_tutorial.html. But this is probably more confusing to users with a functional/simple old-good matlab mindset. If a pyplot import * is safe we could just bring everything into the standard namespace.

[Martyn Gigg]

I agree, I prefer prefixes too but users will expect just to be able to type plot. I suspect most are not well versed in matplotlib either. For mantidplot the mantidplotrc.py file has

import mantidplot
from mantidplot import *

so that both versions with and without a prefix will work. We could do this?

[Federico M Pouzols]

That double import, with and without prefix, looks great. I'd definitely go for it. So pymantidplot.future.pyplot would become pymantidplot.pyplot and then in mantidplotrc.py or mantidplot.py we could have a similar double import:

import pymantidplot.pyplot
from pymantidplot.pyplot import *

[Federico Montesino Pouzols]

move pyplot out of future. and the old plot into qtiplot.py, re #11542

Changeset: be2ae727e628a6eab05200c2bd78791f1b8158c9

[Federico Montesino Pouzols]

fix call to old plot() in test, re #11542

Changeset: 5651f2c48ce8e357f6611b07b21de33b9b1d1541

[Federico Montesino Pouzols]

update rst doc directories and names future.pyplot->pyplot, re #11542

Changeset: e1d8bb65af5124b2ae2327afddfb0ab77d4163f8

[Federico Montesino Pouzols]

update pyplot rst indexes, title and brief description, re #11542

Changeset: f7ac3f81273f309337757f7632ba767bd3007076

[Federico Montesino Pouzols]

add note about DOCS_HTML=ON needed in cmake, re #11542

Changeset: b41ca63426bd81eee691bbefe1c383f4e15209a2

[Federico Montesino Pouzols]

doc update, table of tool names, list of unsupported plots, re #11542

Changeset: d1bcf41b3f56552408ab111e613b655bb62f4c1a

[Federico Montesino Pouzols]

This is being verified as ​pull request #591.

[Federico Montesino Pouzols]

I realized that now that mantidplot.pyplot is loaded by default on start, we get a pretty long message in the logs windows: "You are loading 'pymantidplot.pyplot', which is an experimental module. Please note: this module is at a very early stage of development and provides limited functionality. It is work in progress and is subject to change. Feedback is very much welcome! Please let us know any wishes and suggestions." This used to be fine when users had to load the module manually, but probably we should suppress it now that the module is always loaded.

[Federico Montesino Pouzols]

fix a couple of remaining issues in unit tests, re #11542

Changeset: 213d97cea9423795e15a262c1decb056c4cebc1a

[Federico Montesino Pouzols]

remove verbose message on module load, re #11542

Changeset: 481cc3552d9ca515660001efd57f40d9e4f55d12

[Federico Montesino Pouzols]

import proxies seems to be needed on some platforms, re #11542

Changeset: 3d4d8f4bc77b717308de9583ff13456438783910

[Federico Montesino Pouzols]

PyQt4 import also seems needed, re #11542

Changeset: 11c6e6e24a23e4029eadaa84f793295451f6fe80

[Federico Montesino Pouzols]

Merge remote-tracking branch 'origin/master' into 11542_bring_future.pyplot_into_standard_mantidplot_namespace

Conflicts:

Code/Mantid/MantidPlot/CMakeLists.txt

The 'future' files were still there in another branch, no real conflict here it seems, re #11542

Changeset: 247a4727dca4ccca8fea37cd88c50bd1adba970f

[Federico Montesino Pouzols]

Aha, the conflict seemed to be harmless. I think it's ready now. Let's see what Jenkins says.

[NickDraper]

Merge pull request #591 from mantidproject/11542_bring_future.pyplot_into_standard_mantidplot_namespace

Bring future.pyplot into the standard MantidPlot namespace

Full changeset: ​f4c5fe8fd8bdc6768ffdfe448e902e0971ebd235

[Stuart Campbell]

This ticket has been transferred to github issue ​12380