The majority of credit is due Wes, no doubt, for bringing pandas to life, but it's a glaring omission not to mention the huge contributions from the wider community toward pandas (shout-out to Jeff Reback!) https://github.com/pandas-dev/pandas/graphs/contributors
There were three people who left their full time jobs in 2012 to found a startup with Wes promoting pandas; a year this article highlights as its inflection point in popularity. You were one of them. That omission also seems worth correcting.
Probably also worth at least a small shout-out to the R project (and the S+ and S teams before them) for pioneering the data frame API that Pandas mimics.
For years, I maintained my own python tool for loading/saving CSVs from numpy formats. It was slow, buggy, constantly hitting edge cases. When `pd.read_csv()` and `.to_csv()` came onto the scene, it was like the clouds opened up and a chorus of angels sang. And then you have all the other `read` and `to` functions, it's glorious.
I'm a fan and frequent user of Pandas, but does the increase in Stack Overflow questions indicate a surge in popularity, or difficulty in use? I for one run into Pandas issues frequently and often find myself searching for the succinct solution (though, to be fair, this may also be an indication of the impressive scope Pandas strives for).
I think you're right. There are many, many things I have come across which I search stack overflow excessively because I am overly surprised there isn't a better method of achieving the task. Try and do a cross join in pandas, it's deeply dissatisfying.
Pandas is useful and I don't want to bad mouth it as people obviously find it useful. However, it has a complicated API and contains about 200k lines of code. So, it is not a surprise that documentation is a challenge and that there are lot of Stack Overflow questions. For example, figuring out which method result in copies of the data vs new views is hard.
Compare with dlply. It solves a similar problem as pandas does but has a vastly simpler API. To be fair, Pandas does do more but dlply is also more flexible. I looked at implementing something like dlply in Python but you really need to have a lazy evaluation syntax. dlply makes extensive use of this feature of R. As the downside, it can be very confusing to new users as it is hard to debug this lazy evaluation code.
Rather than adopting Pandas to build our product, I built a very minimal version of it (on top of numpy) that only does what we need. That was some extra work but I'm happy I did it as we avoid this huge dependency. I understand quite well my little minimal version does, it is only about 1000 lines of Python code and some tiny C extensions.
I've used pandas frequently and find their docs to he entirely unsatisfying. Stackoverflow provides examples and fairly good insight on using pandas as a whole compared to the docs which just says this function exists basically.
Pandas has much more breadth than depth. The first few months I used it, I felt the same. At some point it all just clicked and I more or less knew where to look for stuff in the docs.
Anything mildly complex is difficult. And I guess an unpopular tool wouldn't have an increase in questions for a long time. The people would either leave it, or learning. So the number of questions should be decline or at least be around the same number.
I really love pandas and dplyr, but honestly both of them are inferior to modern SQL. In my workflows, I’ve almost exclusively replaced them with Postgres and it’s foreign data wrappers, spit out the results to a text file and then load into R or Python.
It’s a more complicated environment for sure, but still more efficient.
I've found pandas great for interactive sessions, for the most part, but I found doing joins was way too fiddly and I'd much rather do it in SQL. Could be I missed an important pandas concept in there somewhere that would have made it make more sense, or maybe the API has improved since the last time I tried. Generally I've found my SQL ends up being clearer and more readable after the fact.
I haven't tried it but there is a package for R that I find similarly useful, called sqldf. The back end is sqlite, which is quite fast for anything that fits on disk.
I find both hobbled, however, by their rather simple SQL dialects. No window functions, common table expressions, grouping sets or similar, etc. An improvement, no doubt, but Postgres still has it beat.
I honestly wish the vast corpus of effort put into statistics and machine learning in R and Python were more easily portable as Postgres foreign function packages. I've tried the ones I've seen mentioned and they were all horrible, mostly due to embedding an entire language's runtime and memory model on top of the SQL inner workings. A project on my backburner, waiting for the time to work on it :)
I've only touched enough Pandas to get a feel for it, so I'm talking more here about dplyr, but I think most of this applies to Pandas as well.
Yes, SQL is incredibly battle-tested, and has a ton of features that newer systems need to catch up on, and there's a ton of work sunk into performance on too-big-for-RAM datasets that standalone Pandas and dplyr doesn't have. (But see dbplyr, for example.)
But actually programming in SQL sucks. There's no such thing as code reuse, as parameterization, as composability, etc. Everything about DRY goes right out the window when writing SQL and copy-pasta is the law of the land. Writing dplyr is so much more comfortable for me with just a little bit of learning about it. And I think it's going to be so much easier to extend dplyr to cover the gaps between it an SQL than it would be to try and fix the ergonomics of SQL.
This is so true for me as well. I actually use more SQL, Bash, and even MS Access DBs and Excel pivots connecting to text files to get the data in the right, aggregated shape first. Then I load into R or Python as you say so I can work with the data in memory.
Hadley and I are also friends and collaborators! I think we're going to see a lot more interesting collaborations between the R and Python communities in the future, since at the end of the day we're solving a lot of the same problems
Oh yeah, I didn't mean to imply that it wouldn't all be in good fun. I was thinking of the obvious counterpoint for the author to use.
You know Heinrich Wolfflin, one of the pioneers of art history, invented this breakthrough method of teaching where he would set up dual projectors because demonstrating contrasts was a much more effective pedagogical tool than simply describing a painting.
Today, McKinney works full time on Pandas and other open-source data science projects as a software engineer(...)
What? It seems McKinney didn't commit almost anything for the past few years to pandas (not lowering his contribution per-se, but the article made it sounds like he's still dedicated to improvements of pandas).
I've been working on innovating core computational and IO infrastructure for pandas (and projects like pandas) --
much of this work has been happening in other codebases. See: http://wesmckinney.com/blog/apache-arrow-pandas-internals/
Pandas really is great. It's not just that it's a convenient library, it's also really nicely implemented and super efficient. And it has a lot of tools that guide the user towards doing things the right way.
Which photo? The header photo at the beginning of the article with a man working on apple laptop is not Wes McKinney. That is a stock photo of "a man works at his computer at the Airbnb office headquarters in San Francisco" [1]. There is a portrait of the actual Wes McKinney a little ways down the article.
I don't know why QZ thought it is a good idea to start a "Meet the man" article with a large photo of a man who is not the titular man.
