Python Data Visualization 2018: Why So Many Libraries? • Hacker News Board

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

#61

Post by dandellion » Sat, Nov 17, 2018, 12:06 AM UTC

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.

I think what happens with visualization libraries is similar to what happens with things like cars or clothes, there's a lot of diversity because people have different tastes, if it was only about features there would be a lot less variety, but since it's very subjective there's a lot of very similar choices with slight differences and people choose one or another mostly based on personal preference.

Then for other things people will choose based on more objective factors and therefore almost everyone will reach the same conclusion, so you will get only a few choices.

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

#62

Post by msaharia » Sat, Nov 17, 2018, 12:11 AM UTC

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. http://www.ggplot2-exts.org/gallery/

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

#63

Post by gh02t » Sat, Nov 17, 2018, 12:18 AM UTC

carapace wrote: post #45

Remember the old joke, "Python is the only language that has more web frameworks than keywords."? What eventually happened was that the BDFL blessed Django and most of the others withered. Some had enough ecosystem, or were components of some other larger project, or had a niche advantage of Django, and they managed to survive. I think the reason why web frameworks and data viz systems proliferate in Python is just t…

I'd argue exactly the opposite, the reason there are so many is that it's really hard to write a good data visualization framework. Data visualization encompasses a vast range of different tasks that are often only loosely related, and it's extremely difficult (if not impossible) to write one library that serves all uses well. Add on top of that the fact that you have different output types - web, interactive analysis, print etc and you end up with a situation where you get lots of different libraries optimized for different use cases.

And that's not even counting differences of opinion on aesthetics...

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

#64

Post by wodenokoto » Sat, Nov 17, 2018, 12:32 AM UTC

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…

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.

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

#65

Post by _Wintermute » Sat, Nov 17, 2018, 12:42 AM UTC

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…

ggplot2 is great as a high level plotting library, though as soon as you want to do something slightly different you end up in the rats nest that is grob and ggproto (because 3 OOP systems aren't enough, so let's create an entirely new one just for this library). I normally give up and tolerate matplotlib instead.

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

#66

Post by jbednar » Sat, Nov 17, 2018, 1:32 AM UTC

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 the point of HoloViews (http://holoviews.org). But people approach plotting in lots of different ways, and some people actually _do_ want to spend their time making plots, so they are welcome to their ggplot2!

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

#67

Post by laingc » Sat, Nov 17, 2018, 1:36 AM UTC

wodenokoto wrote: post #64

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…

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.

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

#68

Post by abhishekjha » Sat, Nov 17, 2018, 2:16 AM UTC

The more I try to understand plotting documentations the more I end up going to SO for even minute detour from the conventional usecase. This is the same situation with pandas. I wonder how I would ever work with these without an internet connection.

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

#69

Post by bigreddot » Sat, Nov 17, 2018, 2:58 AM UTC

darpa_escapee wrote: post #51

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…

Matplotlib is often a dependency for Python dataviz libraries. I often just skip the middlemen and use it directly. Matplotlib isn't going away any time soon.

MPL is great, but its pretty much only a dependency of Seaborn. It's not a dependency of Bokeh, Altair, or Plotly

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

#70

Post by bigreddot » Sat, Nov 17, 2018, 3:12 AM UTC

carapace wrote: post #45

Remember the old joke, "Python is the only language that has more web frameworks than keywords."? What eventually happened was that the BDFL blessed Django and most of the others withered. Some had enough ecosystem, or were components of some other larger project, or had a niche advantage of Django, and they managed to survive. I think the reason why web frameworks and data viz systems proliferate in Python is just t…

5+ years and 321 contributors later, I can state that Bokeh was not easy to write. Fairly sure MPL and Plotly devs would disagree with this assessment as well.

Python has a multitude of vis systems because there are multiple use-cases, sometimes overlapping and sometimes not, and different people prioritize these very differently (and that's OK).