Shared publicly  - 
 
+Wes McKinney's talk to the NYC Open Statistical Computing meetup on statistical computing in Python and data manipulation using his pandas package.

http://www.vcasmo.com/video/drewconway/13268

Which, seems to have sufficiently rattled the collective R beehive.

https://plus.google.com/109246313993679724191/posts/93DCxiASTsQ
Wes McKinney is a prominent figure in the scientific Python community, and has made tremendous contributions to several core statistical computing libraries in that language. This month, Wes will be ...
4
John Hunter's profile photoGavin Simpson's profile photoWes McKinney's profile photoLaurent Gautier's profile photo
9 comments
 
Gosh, no, you seem to misunderstand, Watson! +Laurent Gautier and I merely deplore the massive creative energy being spent on matters that add few genuinely new tools to the bigger picture. What +Wes McKinney does is all really nice, but seems to fundamentally be merely another blue hammer versus red hammer iteration of "I want the toy the kids over there have". Right, we do have those toys, and we build on them. That said, we are all happy that it leaves all of the cool Python kids so thrilled, but I reckon that the 'collective R beehive' (whatever/whereever it may be) could not really care less. There is always someone inventing the next big thing. Lisp has perfected that for decades, Python has been at it for 15 years, and now gets some more competition from Scala, Clojure, "insert flavour of the month here" etc. It's all good. Imagine if we all had to use VBA or SAS instead :) So really: choice is good, but repetition less so.
 
Understood, and you'll forgive me for the intentionally provocative phrase "collective beehive." But, to answer your question, I think it exists somewhere on the Metra line between suburban and downtown Chicago ;)
 
I'll let the Python community speak for themselves, but I think you underestimate the licensing (GPL vs. BSD-like) issue. If R were BSD, we would be hacking on and contributing to R or otherwise figuring out how to better wed Python and R together. But it's not. Scientific Python is a 99% BSD-compatible ecosystem, and we won't have it any other way.

Secondly, your statement that I've added "few genuinely new tools to the big picture" strikes me as a hasty conclusion and smacks of sour grapes. There are actually some critical deeply integrated features (like data-alignment) that are pretty different from anything I know of in R which make pandas a great tool for certain problems. You can likely achieve the same goals in R, but if you do it with the existing toolset it may come out cobbled-together and kludgy rather than being polished, integrated, and consistent. If I am wrong about this, it would be much more constructive to give concrete examples (code) to prove your points. Your counter argument might be: well, why didn't you just build this library in R? Lots of answers to that but the ones that pop into mind are: a) I want to be able to write data-driven production systems 100% in Python (I am not alone here), not a blend of R and something else, b) I do not like the R language and c) the GPL.

Anyway, these are my final thoughts on the matter for a while-- I need to get back to writing code (!).
 
Maybe you can post a simple blog example showing just the data alignment magic. As this is presumably on time-series (guess from PANel DAta Structures aka "pandas") I would not be surprised if xts's time-index based merge already did something similar. Or will in the near future as +Jeff Ryan is pretty competitive as well :)

As for your 'prefer single language systems': fine, but many (incl. John Chambers) see mix and match as natural. I am not proposing "R only" either. And finally, thanks for your honesty in stating that you "do not like the R language". That explains a lot too, but it puts a clear cap on the usefulness of our discussions here.

As I said, I am strongly in favour of genuinely new stuff, but more or less bored by 'red hammer vs blue hammer' repetitions. I will also leave your repeated license harping alone as most of us using and extending R actually do not have an issue with its license. So let's all get back to coding.
 
Repeated harping? It's a critical issue to those who want to be able to sell proprietary, closed code based on open tools. Most of these people are also making major contributions to the open tools too, and I don't begrudge them wanting to sell some proprietary extensions. Helps feed the kids and all that. Wes is rightly saying that this is an important issue to this community (scientific computing in python), and he's not harping. See for example http://matplotlib.sourceforge.net/devel/coding_guide.html#license-discussion. It's not a red or blue hammer issue, it is an issue of something that can truly be used freely (as in freedom) versus not.
 
This is an important aspect of Open Source software, and a complex one: one is completely free to use while the other tries to ensure that it will always be free by limiting present-time freedom, one make the accumulation of value in products possible while the other limit that value and mostly make service the valuable part.

However, the discussion, and disagreement, started over quite different points but this remained locked in a non-public thread. That first round had the merit to leave one thing unresolved: this is all about being able to monetize work under a permissive license. A BSD vs GPL case. Should this have been presented upfront, and no matter how irreconcilable the two licences can be, I believe that there would have been a different discussion.
 
+John Hunter GPL is irrelevant to using code freely. Only distribution is affected. The world would have been worse off if R had not been released as open source. I'm glad it is GPL because it stops people taking it and releasing closed extensions available to the privileged few with money. Especially when the killer feature of R are the add-on packages - most of which are also totally free and open. I don't mind people making money of open source, but you don't need to do that via proprietary add-ons. Sell support and expertise. Red Hat has done pretty well with this model.
 
+Laurent Gautier I'm not sure I understand you correctly. If R were BSD I would personally still be programming in Python for aforementioned reasons (and those that were in the non-public thread), but along the way I might have made an effort to reuse software components from the R project, something that is not currently feasible (under a permissive license).
 
+Wes McKinney By this I mean that the discussion might have started differently. Say in the beginning "yes, I do reimplement functionailties I like under a BSD licence" and there is little that can argued about beside "why can't use GPL code" (and it usually ends with "check with a lawyer" ;-) ). I read more myself on the issue since this stared and while there is no clear cut, it made me see the extent of the problem for people wanting to distribute closed source code. Now I have some ideas around that, I hope to have code to demonstrate them by the end of the year.
Add a comment...