Plotly.py: 2.0.0 Wishlist

Created on 30 Dec 2016 · 21Comments · Source: plotly/plotly.py

@chriddyp @Kully @cldougl

I haven't had many cycles to play around with the python api library lately, but recently got in a little deep for https://github.com/plotly/plotly.py/pull/640, where we've now got fully-unified api modules.

I think enough shifted (mostly additions, but the error handling is definitely not backwards compat) that we should open up a discussion on non-minor changes that we've been looking to add to the plotly module. Here's a list of topics:

[x] API request/response unification (https://github.com/plotly/plotly.py/pull/651)
[ ] Fix or drop support for matplotlib
[x] Add numpy as an official dep. and use it to speed up the library. (#667)
[x] Related to above, clean up how we handle optional imports (https://github.com/plotly/plotly.py/pull/317)
[x] Stop auto-loading graph reference and just use packaged graph reference (https://github.com/plotly/plotly.py/pull/614)**
[x] ~~Add transforms to graph objects (https://github.com/plotly/plotly.py/issues/587)~~ holding off on this until the transforms spec settles in plotly.js.
[x] Add frames for graph objects (https://github.com/plotly/plotly.py/issues/604)
[x] Add a sign_in validation #525 (#668)
[x] ~~Fix up streaming? (this might be more work than it's worth at this point https://github.com/plotly/plotly.py/pull/253)~~ No time for this atm.
[x] Some module re-organizing. Most importantly, we should move FigureFactory into it's own sub-package and each Figure-generator should be it's own file. The tools.py module is enormous and is a constant point of pain for circular imports (https://github.com/plotly/plotly.py/pull/652).

*In fact, if we *do do this, we can just add some meta programming to auto-create a module full of all the objects from graph-reference. This way we don't have those dump "Scatter is not defined" errors, etc.

Anything else?

Source

theengineear

👍2 😄1

Most helpful comment

Add numpy as an official dep. and use it to speed up the library.

I'm OK with using this in all of our FigureFactory methods but I'd still like to keep this as a protected import. I think there will still be new users who might have trouble installing it on their machine with their default python distribution.

chriddyp on 2 Jan 2017

👍2

All 21 comments

I'm still going to be working mostly on frontend code, but I'd definitely be interested in making some non-trivial improvements here. Thoughts?

theengineear on 30 Dec 2016

Add numpy as an official dep. and use it to speed up the library.

chriddyp on 2 Jan 2017

👍2

For 2.0.0, I think that we only need to consider backwards incompatible changes if we're going to version as according to SemVer. In other words, it doesn't need to be a big release.

Here's an interesting discussion on this: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e

So, from that list above, it seems like:

Add transforms to graph objects
Add frames to graph objects

could be done in either 1.x or later in 2.x

chriddyp on 2 Jan 2017

Ok, I sorta thought we were trying to strive for SemVer. I feel pretty confident that I don't want to change how errors work in a non-major version change. I'd be pretty annoyed if I upgraded a minor version and all of a sudden all my exceptions were being caught like they were before!

The point about the 1% breakage is interesting, but it assumes that you can actually know what users are doing with your code.

Perhaps were just too stuck on the idea of having a major, romantic 2.0.0 release. I'm not suggesting that this needs to be monumental, but there are a couple breaking api changes that we'd like to make and we want to make those clear to users.

So, from that list above, it seems like...

👍 , those can be in 1.x.

theengineear on 4 Jan 2017

Now that I think about it a bit more, I don't think that the no-auto-load-graph-references needs to be in 2.x either, right?

@chriddyp ^^

theengineear on 4 Jan 2017

Ok, I sorta thought we were trying to strive for SemVer.

Yeah sorry for the confusion, I think that we're striving for SemVer too. I just posted that link to mention the alternative where we put "big features" in major version releases (which we don't need to do if we're doing SemVer).

chriddyp on 4 Jan 2017

I don't think that the no-auto-load-graph-references needs to be in 2.x either, right?

👍 , yeah. The auto-updating makes it a little bit weird. If Version 1.20 removes graph-reference, then someone on Version 1.19 (with auto-updating graph reference) could end up with a newer graph reference than the user in Version 1.20. That being said, we only guarantee the graph reference that is actually shipped in the package.

chriddyp on 4 Jan 2017

Add numpy as an official dep. and use it to speed up the library.

This goes hand in hand with the trisurf optimization stuff which I still have to put back in (@choldgraf 's improvements).

Kully on 6 Jan 2017

^^ @Kully , I'm going to fix up our optional imports and then we're going to just liberally use numpy scipy pandas in the FF stuff.

theengineear on 6 Jan 2017

+1 for supporting the scientific python stack (numpy, scipy, maybe pandas). I think your target audience (at least the ones that want to use the python API) will already be using it.

choldgraf on 6 Jan 2017

Getting there with frames support. It's tricky because it's a top-level attr on figure, which we already make up in the plotly python api (figure is not in plot-schema).

theengineear on 9 Jan 2017

Wow, everything done up in the top comment but matplotlib. @chriddyp any thoughts on that? I feel weird about keeping it around if no one has time to maintain it. It's sorta destined to be more and more broken...