Consolidate plot options processing into PlotOptions

[bdlucas1]

Sorry about the size of this PR - I tried to find a way to do it more incrementally, but things were too tangled for me to figure out how to do that.

The main thrust of this PR is to consolidate options processing for plots in a common class, PlotOptions, eliminating as much duplicate code as possible. PlotOptions was created initially for and shared by the 3d plots that inherit from _Plot3D in plot_plots3d.py. With this PR it has been generalized and is also used by the plots in plot_plots.py that inherit from _Plot.

(With one exception: DiscretePlot is in plot_plots.py and inherits from _Plot, but it calls eval_ListPlot. TBD whether or how that can be untangled in a future PR).

I also tried to move the Python data structures in PlotOptions to use Symbols instead of strings. To facilitate this I added a keyword argument, preserve_symbols, to to_python. The effect is Symbols are not converted to strings if this arg is True.

All tests pass and I've also verified locally through automated testing that images generated from the Plots for the doctest tests (and more) both via Plotly (m3d) and via SVG are unchanged.

[rocky]

Please let's add docstrings and sort orders, where needed, to the top of builtin.drawing.plot*.py files.

[bdlucas1]

Added the docstrings, and also un-DRYed the sort_order thing (although unless the doc system is examining the text of the modules or parsing it to an AST I don't think it would see any difference).

[rocky]

Please let's add docstrings and sort orders, where needed, to the top of builtin.drawing.plot*.py files.

Sorry, I mean user-centric documentation. This is how one docstring currently renders in the user-facing documentation:

I was hoping for something that says something about the general characteristics of a List Plot, as opposed to a Chart kind of plot or a 3D plot.

Please also see https://mathics-development-guide.readthedocs.io/en/latest/extending/developing-code/extending/documentation-markup.html#guidelines-for-writing-documentation

[rocky]

I think if you just remove this line and the other lines like this altogether, the right thing will happen since mathics.drawing.plot_listplot comes lexically before mathics.drawing.plot_plot which comes lexically before mathics.drawing.plot_plot3d.

[bdlucas1]

Sorry, I mean user-centric documentation.

I don't think there is particularly any user-centric meaning to those modules - for example, ContourPlot and ComplexPlot3D are both in plot_plot3d.py because they share implementation (_Plot3D base class), but that has no significance to an end-user.

If module structure dictates document structure then probably some rearrangement of module structure will be needed here. This PR is already large - can we keep it focused on the code structure and solve the #1557 documentation issue in a separate future PR?

[rocky]

Sorry, I mean user-centric documentation.

I don't think there is particularly any user-centric meaning to those modules - for example, ContourPlot and ComplexPlot3D are both in plot_plot3d.py because they share implementation (_Plot3D base class), but that has no significance to an end-user.

Well, they are both 3-parameter-valued plots shown on a 2D screen, and that's why they share the same code. I'm okay with saying something along those lines and leaving the rearrangement of modules or finer points for later.

In the case of charts and list plots, the user-centric description though, is clear.

If module structure dictates document structure then probably some rearrangement of module structure will be needed here. This PR is already large - can we keep it focused on the code structure and solve the #1557 documentation issue in a separate future PR?

Personally, I do use the documentation, such as it is, and when it is broken like this, it makes it harder for me to figure out what's up. When things get inadvertently broken as a result of an inattention to detail, I would hope there's a priority for addressing this over going further down the rewrite structure, and possibly as an afterthought we fix up the stuff that got broken along the way. (Unless, of course, we know that this kind of thing is going to happen and we agree to let things stay broken until the end.)

It is not that hard to write something reasonable here. If you don't want to do it, let me know, and I'll suggest some text to add. I don't think it's all that difficult a thing to do.

Please let me know your thoughts.

[bdlucas1]

Feel free update the PR with whatever text will help you.

[rocky]

Feel free update the PR with whatever text will help you.

Oh, that reminds me of one other thing... when you put in PRs, it helps if you do it in a branch in this repository (as opposed to bdlucas1).

It makes this kind of suggesting changes to the PR easier. Thanks.

[bdlucas1]

Oh, that reminds me of one other thing... when you put in PRs, it helps if you do it in a branch in this repository (as opposed to bdlucas1).

OK, will do. At one point I think I didn't have the ability to do that so just did it as a branch in my fork. Will look into how to do it as a branch in this repo.

[rocky]

Thanks!

[bdlucas1]

I'll suggest some text to add.

@rocky when you've had a chance to come up with the text you want let me know and I'll update the PR.

[rocky]

I'll suggest some text to add.

@rocky when you've had a chance to come up with the text you want let me know and I'll update the PR.

I'll add the text as a PR to your PR after you've rebased this from this repository. Thanks.

[bdlucas1]

I'll add the text as a PR to your PR after you've rebased this from this repository. Thanks.

Sorry, I don't know what that means exactly or how to do it - I'm not very facile with github branches. I guess you're referring to your previous comment about submitting PRs using branches from this repo, but I thought we were talking about future PRs. I have figured out how to do that and will do so in the future. Can we continue with this PR in its current form?

[mmatera]

I'll add the text as a PR to your PR after you've rebased this from this repository. Thanks.

Sorry, I don't know what that means exactly or how to do it - I'm not very facile with github branches. I guess you're referring to your previous comment about submitting PRs using branches from this repo, but I thought we were talking about future PRs. I have figured out how to do that and will do so in the future. Can we continue with this PR in its current form?

I take that part

[rocky]

I'll add the text as a PR to your PR after you've rebased this from this repository. Thanks.

Sorry, I don't know what that means exactly or how to do it - I'm not very facile with github branches. I guess you're referring to your previous comment about submitting PRs using branches from this repo, but I thought we were talking about future PRs. I have figured out how to do that and will do so in the future. Can we continue with this PR in its current form?

I take that part

Thanks @mmatera !