Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Data Visualization 2018: Why So Many Libraries?

anaconda.com

Post reply on HN
Print view View original

71–80 of 105 posts

Re: Python Data Visualization 2018: Why So Many Libraries?

#71

Post by derefr »

makmanalp wrote: post #31
ms013 wrote: post #17

Earlier quoted context omitted.

Yup. A likely result is that if you pick one and spend the time to learn it and use it for a project, there's a non-trivial chance that the choice you make will be join the ever growing collection of library abandon-ware in the not too distant future. This is why my favorite Python visualization tools are not Python - I've been burned too many times by libraries coming and going, and I just don't have the time to spe…

Argh, it's so frustrating to see this kind of sentiment. We're truly spoiled by choice. The libraries don't all serve the same purpose, and not everyone needs every library. This is literally a guide to help pick which one I may want. What more could one ask for?? That said, I understand it sucks to build on top of someone else's code only to have it be discontinued, but honestly it only takes a few minutes to judge…

> What more could one ask for??

A refactoring and merging of these libraries to enable fewer people to maintain more functionality, such that the bus-factor of any given part of the functionality is higher.

Re: Python Data Visualization 2018: Why So Many Libraries?

#72

Post by stuartaxelowen »

domoritz wrote: post #43
TheAlchemist wrote: post #5

Altair hands down. I've tried and worked with a lot of those in data analysis, Altair just seems like 'magic'. What should be easy is easy, what is hard is still possible - for me it's the perfect mix. The only (but a big one) drawdown is the peformance implication of the JSON generated for chart - over 50k lines of raw data for chart, you start to feel the lag.

Vega-Lite author here. Performance is hugely important for us and is covered y the first three points on our roadmap: https://docs.google.com/document/d/1fscSxSJtfkd1m027r1ONCc7O... . Some improvements will ship with Vega-Lite 3. Others are being worked on as we speak.

I love vega-lite, thank you so much for your hard work!

Re: Python Data Visualization 2018: Why So Many Libraries?

#73

Post by bigreddot »

derefr wrote: post #71
makmanalp wrote: post #31

Earlier quoted context omitted.

Argh, it's so frustrating to see this kind of sentiment. We're truly spoiled by choice. The libraries don't all serve the same purpose, and not everyone needs every library. This is literally a guide to help pick which one I may want. What more could one ask for?? That said, I understand it sucks to build on top of someone else's code only to have it be discontinued, but honestly it only takes a few minutes to judge…

> What more could one ask for?? A refactoring and merging of these libraries to enable fewer people to maintain more functionality, such that the bus-factor of any given part of the functionality is higher.

That's entirely backwards, to reduce the bus factor, you need more people maintaining less, not fewer people maintaining more.

In any case, the incentives are simply not there, as different projects have very different priorities (which is why there are so many projects). Some folks want to monetize their special sauce (Plotly). Some folks want to focus on high level statistical charting (Altair, Chartify) Some folks want to focus on interactive data exploration (Holoviews) Some folks want to focus on high performance and streaming (Bokeh) Some folks want to focus on high quality static image generation (MPL). The human and economical cost of getting all those groups under one tent is astronomical.

Re: Python Data Visualization 2018: Why So Many Libraries?

#74

Post by wodenokoto »

laingc wrote: post #67
wodenokoto wrote: post #64

Earlier quoted context omitted.

There's a lot of good things to say about ggplot, but I feel like the best thing is RStudios ability to auto-complete column names of the input dataframe throughout your pipe of ggplot commands / functions. I think I would enjoy Python just as much if I figured out how to auto complete column names when writing code for my plots and pandas operations.

Pandas dataframes can autocomplete column names using the dot syntax.

I know I can auto complete with

    df.mycolumn
But what about

    df.sort_values(by='mycolumn')
In that kind of cases RStudios is smart enough to know that such an argument should be populated by a column name from the dataframe that function is being applied to.

Re: Python Data Visualization 2018: Why So Many Libraries?

#76

Post by RobinL »

msaharia wrote: post #62

Python visualization needs a visionary like Hadley Wickham. Once you get used to the clarity of "Grammar of Graphics", every other plotting library feels like a clumsy tool. Also, people pointing out the diversity of needs behind the multiverse of plotting libraries in Python probably aren't aware of the large number of extensions built on top of ggplot2[1]. In python, they end up being completely new packages. 1. ht…

I think we have one in the team behind Vega Lite. Vega has a concise and well-designed grammar of graphics. It comes from the same academic centre (UW Interactive Data Lab) where Mike Bostock developed d3, and I think complements d3 nicely as a higher level tool.

Hadley Wickham's slightly abortive ggvis project was a wrapper around Vega.

Altair is the python library that wraps Vega Lite, making it even more concise to write chart specs.

One important unique feature is that Vega and Vega Lite (and Altair) provide declarative syntax for complex interactions such as cross filters.

I wrote a blog post recently with much more detail about all of this: https://medium.com/@robin.linacre/why-im-backing-vega-lite-a...

Re: Python Data Visualization 2018: Why So Many Libraries?

#77

Post by gaius »

jbednar wrote: post #66
msaharia wrote: post #62

Python visualization needs a visionary like Hadley Wickham. Once you get used to the clarity of "Grammar of Graphics", every other plotting library feels like a clumsy tool. Also, people pointing out the diversity of needs behind the multiverse of plotting libraries in Python probably aren't aware of the large number of extensions built on top of ggplot2[1]. In python, they end up being completely new packages. 1. ht…

Personally, I don't _want_ a grammar of graphics; I want a grammar of data, where the data happens to have a graphical representation. I don't want to spend ages piecing together a fancy plot; I want to spend just a little time annotating my data to declare what it means, and then no matter how I slice and dice my data it will show up in a meaningful way. That way I can explore it to really understand it, which is th…

I don't _want_ a grammar of graphics; I want a grammar of data, where the data happens to have a graphical representation

The point of having a graphical representation is to communicate with other humans therefore some subjective judgement is required; there’s no “one true plot” for each type of data.

Re: Python Data Visualization 2018: Why So Many Libraries?

#78

Post by gaius »

ms013 wrote: post #17
frankc wrote: post #16

There's like 15 comments in this post and 10 different suggestions on what visualization library to use. That's not great.

Yup. A likely result is that if you pick one and spend the time to learn it and use it for a project, there's a non-trivial chance that the choice you make will be join the ever growing collection of library abandon-ware in the not too distant future. This is why my favorite Python visualization tools are not Python - I've been burned too many times by libraries coming and going, and I just don't have the time to spe…

there's a non-trivial chance that the choice you make will be join the ever growing collection of library abandon-ware in the not too distant future.

I’ve been using Matplotlib for the last 10 years and expect to continue using it for the next 20. The stability is there, you just need to resist the urge to keep switching. It’s like vi: whatever your “favourite” editor is, you know that vi will always be there.

Of course as others have said ggplot2 is better but I am going to check out plotnine now...

Re: Python Data Visualization 2018: Why So Many Libraries?

#79

Post by billfruit »

Perhaps atleast some of the python visualization libs are built upon Matplotlib. I do feel that Matplotlib is kind of unintutive, trying in some ways to emulate Matlab, which isn't an elegant system to start with. For people directly using python without any prior experience with matlab, that is unnecessary baggage.

Also 3d plotting and graphing needs much more features. Trying to plot vectors in 3d, I found things are still very rudimentary. Even for surfaces, if you want to plot an ellipsoid, for eg, you need to reformulate the surface in polar form, then only matplotlib is able to generate it, were as Mathematica can generate surfaces from Cartesian expressions.

Re: Python Data Visualization 2018: Why So Many Libraries?

#80

Post by sgillen »

I wonder if it's too easy to make one of these libraries. Don't get me wrong I'VE never tried to build one of these, I'm sure it's hard. But maybe it's not so hard that people won't just make their own that fit their needs better.

If this is true I would say it's a positive feature of python, but also a reason for fragmentation. You tend to see less fragmentation in earlier and lower level technologies. This is partially due to time, only good software or hardware lasts. But I also hypothesis it was because things are harder down there, you need bigger teams and more resources, which tends towards centralization.

Post reply on HN