Can someone explain what the difference is between using graphical objects (go) and figure_factory (ff)? I vaguely remember there being a third one (px?) as well.
I’m not sure what I’m supposed to use. Some of the arguments only seem to work for ff, others only work for go. It’s probably because I’m not using the arguments correctly, but I haven’t seen any explanation in the documentation as to why all these different methods exist and when it is appropriate to use each one.
Great question! @nicolaskruchten wrote a very extensive chapter on all of the different forms here: https://plotly.com/python/creating-and-updating-figures/. Let us know if you have any questions after reading that through and we’ll be happy to answer (and we’ll try to update that guide with the answers too).
Thanks, that helps clear up some of the questions I had. I didn’t understand that plotly.py was basically just a wrapper for plotly.js (I’m not really familiar with either one, although I’m learning). But it makes sense how it works.
Plotly express seems to be used primarily for converting dataframes into graphical objects (although this isn’t explicitly stated anywhere), and figure factories say “its for specialized domains”, although it doesn’t really explain what these domains are. I guess I am still a little confused as to why these aren’t all rolled into a single package? Having to learn the conventions of three different packages as opposed to one seems to steepen the learning curve without providing many additional benefits, at least none that are obvious to me.
As a side note, do you know why my PyCharm code auto-completion would not be working in the below example:
Based on this documentation you’ve linked, I should be seeing functions like update_layout() and update_traces() in the autocomplete suggestions.
The way to think about Graph Objects (go) vs the other layers is that they are a one-to-one mapping to the underlying rendering system (plotly.js) and the other layers exist to make it easier/faster to configure a set of go objects into the visualization you want. They are totally programmatically-generated from the underlying Javascript library description, so whenever the JS library gets a new feature, changes happen in the go layer. You can use them directly if you like, or you can use the higher-level wrappers: whatever makes you comfortable.
The way to think about Figure Factories (ff) vs Plotly Express (px) is that the ffs were built first, one at a time, to solve specific individual visualization problems, whereas px was built later with a much more general-purpose approach, and in fact PX can be used in place of certain ffs now. We keep the ffs around for backwards-compatibility reasons mostly: we are not adding any features to them or building new ones any more.
This makes a lot of sense. I think it would be helpful to add something like that to your documentation referenced by @chriddyp earlier, especially about figure.go being a 1:1 relationship to plotly.js.
I find it confusing that some of the examples in the documentation still use figure_factories if they are depreciated (I also don’t get a depreciation warning when using them). I think it would make things less confusing if the dash team removed them. Having three different ways to do things makes the learning curve exponentially harder. It’s one of my biggest complaints about pandas - you can do things like df.loc, df.ix, df[df[a== “a”]], df.query(), and several other variations to do the same thing. In some cases, only one way of these is the right way for the operation you’re trying to do. Sometimes you’ll get warnings if you do it the “wrong” way, and sometimes it won’t work at all. It’s a crapshoot choosing the right method, and it means I have to learn more than one method to do the same thing. It’s most likely that I don’t understand the underlying code or the reasons things were done the way they were (just as I don’t understand plotly yet), but that doesn’t take away from the fact that it makes it harder to learn because I’m constantly shifting the basis of where I’m learning from. To use an analogy, it’s like trying to learn math by being taught traditional math and common core math at the same time, and constantly switching back and forth between the two mid-lesson. The symbols and the end results of traditional and common core similar, but conceptually they are very different. It’s much more effective to just be taught one approach. Once you understand it from a higher level perspective, it’s easier to go back and learn the other method. At a minimum however, providing an explanation up front like the one you did would be helpful.
I don’t know what the best way to solve this is (or if it even needs to get solved - that’s a discussion for your team) and it’s probably not something high on plotly’s priority list, but I did want to offer the feedback as it seems like an area that could use improvement in a long-term perspective.
we appreciate the feedback @BigSteak4! definitely something we’ll be working on going forward, we’ll keep this thread updated with progress 
Thanks for the feedback! So https://plotly.com/python-api-reference/plotly.figure_factory.html lists all the figure factories and we’ve tried to indicate there which ones are deprecated, in the docstrings. We don’t like to throw warnings because it annoys users of old code, and we’re not really intending to remove these functions any time soon.
In terms of the documentation pages, we’ve tried to make it clear on a case by case basis which ones are deprecated. For example we don’t even mention the violin-plot ff on the violin plot page but in the dist-plot page we do mention the figure factory as an alternative, and ditto in the choropleth page. The Gantt page still lists the figure-factory as the best way to make this kind of chart, and the same holds for quiver plots, streamline plots and ternary contours. As we improve Plotly.js and Plotly Express we go through and update the docs with the new recommended way to do things, but I agree it’s a bit confusing 
I’ll close by saying there’s no “right” or “wrong” way to make a figure in Plotly from my point of view: we work very hard to maintain backwards-compatibility with “old” ways of doing things, and we continually work to make easier-to-use and more-general “new” ways of doing things like with new trace types and Plotly Express, and our approach is to emphasize the new and recommended in our docs, and to slowly displace the old in our docs without necessarily telling people to stop using them, or forcing them to by removing them from the library. In certain cases, although PX is the new recommended way, the Figure Factory has certain extra capabilities that haven’t been completely superseded yet, and so we don’t want to force anyone to switch to what they would perceive as an inferior alternative.
Update: I’ve just added this page https://plotly.com/python/figure-factories/ and back-linked to it from all the pages listed therein which document non-deprecated Figure Factories, and I’ve linked to it from https://plotly.com/python/creating-and-updating-figures/
Hopefully that helps a little bit! I’m planning on writing some clearer docs about Graph Objects vs Plotly Express in the coming days also.
FYI @BigSteak4, we’ve made some progress in better top-level documentation explaining everything from first principles. Would love your feedback!
These new sections are in the “Fundamentals” part of the home page:
and more here: https://plotly.com/python/plotly-fundamentals/
There is more detail on these pages in this announcement: 📣 Big new documentation page: The Figure Data Structure
I love the new Fundamentals page. It helped me get through some challenging graph updates I needed to implement. I also really appreciate the new api documentation on graph_objects and plotly express.
I created this tutorial in hopes of giving an overview of plotly, which also explains the difference between plotly express and graph_objects.
See tutorial here.
