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

41–50 of 105 posts

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

#41

Post by marmaduke »

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…

I don’t really get this. I’ve used Matplotlib for the last ten years, and it just gets better.

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

#42

Post by marmaduke »

It seems like a common critique of Python is that there’s choice in which tool to use for a given task (serve web, fast numerical code, and here, visualization). This is ironic given a language that says there should be one obvious way to do it, but perhaps it reflects a diversity of applications, similarly to how enterprise Java seems overengineered until the day that that dependency injection mumbo jumbo allows you to cover a paying use case that would’ve otherwise taken ages.

If I want pretty web-ish scatter plots Bokey or Plotly, and if I need desktop GUI visualizations, PyQtGraph, etc. Thankfully there’s no one saying we need a single toolkit for everything (though Matplotlib does try to do this to some extent)

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

#43

Post by domoritz »

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.

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

#44

Post by dswalter »

marmaduke wrote: post #41
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…

I don’t really get this. I’ve used Matplotlib for the last ten years, and it just gets better.

From an ease-of-use perspective, it certainly had the room to improve.

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

#45

Post by carapace »

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 that they are so easy to write, yet still challenging enough to be really fun, and you get a lot of highly, uh, visible feedback and reward for doing it.

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

#46

Post by noobermin »

marmaduke wrote: post #42

It seems like a common critique of Python is that there’s choice in which tool to use for a given task (serve web, fast numerical code, and here, visualization). This is ironic given a language that says there should be one obvious way to do it, but perhaps it reflects a diversity of applications, similarly to how enterprise Java seems overengineered until the day that that dependency injection mumbo jumbo allows you…

Ideology is meh. I always took the whole "there should be one obvious way" as a guideline for the language or libraries close to the core. Who cares if it isn't that way for everything? Data visualization is a library at the end of a pipeline, which make the requirements for it to interface with anything else much less stringent as it is for the standard library for example.

It's fine you have multiple tools. The only thing that matters at the end of the day is the product you provide, so it doesn't seem to matter to me.

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

#47

Post by RyEgswuCsn »

minimaxir wrote: post #4

I'm pretty good at Python and do most of my work in it nowadays, but if I need to make a data visualization, I still go to R just for ggplot2. Nothing currently in Python compares (not even the "ggplot2 port"), and it takes an order of magnitude longer to make a comparable viz.

If you are using Python with Jupyter notebooks, another way to create graphs with ggplot2 is to interface directly with an R session using the rpy2 package. A nice tutorial can be found here: https://www.linkedin.com/pulse/interfacing-r-from-python-3-j...

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

#48

Post by makmanalp »

minimaxir wrote: post #4

I'm pretty good at Python and do most of my work in it nowadays, but if I need to make a data visualization, I still go to R just for ggplot2. Nothing currently in Python compares (not even the "ggplot2 port"), and it takes an order of magnitude longer to make a comparable viz.

I heartily recommend altair, which is maturing nicely - while the API is not a clone of ggplot, it takes the same grammar-of-graphics idea and applies it to interactive graphics.

It's 5-6 lines of code per chart for most examples here, with a few more lines for interaction (e.g. selection and linked brushing across graphs).

https://altair-viz.github.io/gallery/index.html

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

#50

Post by [deleted] »

noobermin wrote: post #46
marmaduke wrote: post #42

It seems like a common critique of Python is that there’s choice in which tool to use for a given task (serve web, fast numerical code, and here, visualization). This is ironic given a language that says there should be one obvious way to do it, but perhaps it reflects a diversity of applications, similarly to how enterprise Java seems overengineered until the day that that dependency injection mumbo jumbo allows you…

Ideology is meh. I always took the whole "there should be one obvious way" as a guideline for the language or libraries close to the core. Who cares if it isn't that way for everything? Data visualization is a library at the end of a pipeline, which make the requirements for it to interface with anything else much less stringent as it is for the standard library for example. It's fine you have multiple tools. The onl…

[deleted]
Post reply on HN