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

31–40 of 105 posts

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

#31

Post by makmanalp »

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…

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 a project's maturity. Here are some very easy rules of thumb. Don't write a lot of important code relying on a library that:

- Is younger than 3 years old. - Has less than 3-4 major contributors and 20 overall contributors. - Has lost steam: a lot of issues and pull requests open and stale with no triage tags, no discussion or responses. - Doesn't seem to have any automated testing / packaging infrastructure set up. - Doesn't seem to have a regular ongoing cycle of releases, be it long or short. - Doesn't have nicely laid out documentation. - Doesn't seem to have a user base, as indicated by a preponderance of questions and answers on stackoverflow, etc. - Just posted their "we made a cool new thing" post on HN a few weeks ago.

Yes, the cutoffs are arbitrary (and flexible!), but this hasn't failed me yet. The python world is filled with many wonderful and mature libraries. It just also has a lot of up and coming, promising young ones. Use whichever!

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

#32

Post by minimaxir »

dnhz wrote: post #29
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.

How do you transfer data from Python to R? I like the look of ggplot2, but most of my data I keep as pickle files.

Exporting as a CSV (e.g. pandas's to_csv) works fine, since R/ggplot2 expects tabular data.

You probably shouldn't be keeping data as pickles, for both compatibility and security reasons.

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

#33

Post by whorleater »

thicknavyrain wrote: post #30
cozzyd wrote: post #26

As a ROOT guru and occasional pythonist, I recommend PyROOT especially if you want to interactively explore what you're plotting.

Does anyone outside of High Energy Physics use ROOT? I'm not trying to be argumentative, I'm genuinely curious, I'm a physicist by day so seeing ROOT talked about on here amongst popular libraries is like someone recommending my local pub as the best in town.

I used root in astrophysics for a couple things, but that's hardly outside it's intended audience. yt is generally considered to be easier to pick up now instead though.

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

#35

Post by [deleted] »

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…

[deleted]

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

#37

Post by noobermin »

cwyers wrote: post #28

The reason there's so many libraries is that none of them has emerged as a clear leader. If there was one really great library for the majority of use-cases, you'd see consolidation around it, like you mostly have with ggplot2 in R.

A variety of choice is fine. It certainly doesn't hinder anyone.

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

#39

Post by noobermin »

whorleater wrote: post #33
thicknavyrain wrote: post #30

Earlier quoted context omitted.

Does anyone outside of High Energy Physics use ROOT? I'm not trying to be argumentative, I'm genuinely curious, I'm a physicist by day so seeing ROOT talked about on here amongst popular libraries is like someone recommending my local pub as the best in town.

I used root in astrophysics for a couple things, but that's hardly outside it's intended audience. yt is generally considered to be easier to pick up now instead though.

yt is magnitudes better than root that putting them in the same sentence is as sensible as comparing apples to jurisprudence.

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

#40

Post by MereInterest »

cozzyd wrote: post #26

As a ROOT guru and occasional pythonist, I recommend PyROOT especially if you want to interactively explore what you're plotting.

As someone who used to use ROOT, I would strongly recommend against it. Its C++ implementation has all manner of hidden state, and this leaks into PyROOT.

For example, ROOT has the concept of ownership, entirely distinct from the python sense of references. A file owns the histograms that were read from it. Closing the file changes all references to histograms read from that file to None. It took a large amount of digging to figure out how that was even possible (overwriting an existing object from within the C API), but I cannot for the life of me understand why.

ROOT has way too many gotchas for me to ever recommend it.

Post reply on HN