So, first, apologies for this being so big. I needed a column chart and the ability to get the JS code and each change followed from there.

All of the changes are essentially backwards compatible. The biggest change is that the chart methods no longer automatically open the Jupyter notebook or web browser on every call. dispFile() (or its new alias, show) needs to be called explicitly unless the nb parameter of the chart method is True.

This change allows stuff like the following:

>>> fig1 = figure()
>>> fig1.plot([1,2,3,4])
>>> str(fig1)
[The page source]
>>> fig1.get_drawChart()
[The JS code of just the drawChart method]
>>> fig1.show()
[write the file, open the notebook/web browser]
>>> fig1.write()
[just write the file]
>>> fig1.nb()
[open in notebook]
>>> fig1.wb()
[open in browser]

So, the obvious way this is not 100% backwards compatible is that anything relying on the chart to appear directly after plot is called now needs to be followed by show. All code using the methods like plot_nb works with no change because I retained the chart method parameter nb, as explained above.

Another change is that dispFile now automatically detects if you are in a notebook. If you are, it displays in the notebook by calling nb(). If you are not, it opens in a web browser. The boolean parameter nb on this method now does nothing, and raises a DeprecationWarning if you're running the code with python -W on.

Also, I moved the templates out of the gpcharts.py file because they were in the way. Because this package in intended to be installed via PIP, there's no specific benefit to keeping those in the main file.

The version on PIP breaks, currently.

The line that used to import _templates.py needs to be removed.

I'm just raising a new issue so you'll be sure to see this. I'll fix this after work, if you haven't.

I tried to use the backslash \ to fix the broken image link, but for some reason that wasn't working as well. So then I looked at how other files in the "assets" directory are named. And followed the same convention. And now the README.md is fixed.

Before

After

The new feature

This uses **kwargs to allow a user to specify arbitrary options to the plot methods, opening up all the customization potential of the Google Charts API. Here's some example usage.

Neither of these figures will have legends:

from gpcharts import figure

f1 = figure()
f1.plot([1,2], legend="'none'")

f2 = figure()
op = {'legend':"'none'"}
f2.scatter([1,2,3],**op)

An interesting consequence

fig.plot(xdata=data, curveType="'asdfasdf'")

If there is more than one instance of a key within the JavaScript options dictionary, the last assignment of the key is used. That means these options can override GooPyCharts default settings. Users can do whatever they want!

As you know, GooPyCharts defaults to curveType = 'function'. Any invalid string (like this example's asdfasdf) makes Google Chart API use its default behavior: straight lines. You could, of course, also write 'straight lines', but, for this demonstration's purposes, that would obfuscate what's really going on.

It is presumed that Python4 will be mostly, if not completely, backwards compatible with Python3. At the same time, it will not revert to Python2 compatibility. As such, Python3 patches like this should also be written to be seen by future versions of Python, so they're less likely to break with that eventual update.

I realized this after reviewing the code the other day, but a line like this is possible:

fig5.scatter([1,2,3,4,5],[[1,5],[2,4],[3,3],[4,2],[5,1]],
             trendline=True, trendlines="{}")

This is a chart where we indicate that we use the trendline option, but also provide an empty trendlines option as an "other" option. No trendline appears.

Under the hood, the trendline option is added before other options, so the other options take precedence and the conflict is possible.

So the question is: do we care? It seems like a really niche thing that could only be unintentional, but it is still possible.