News for hackers. Stuff that matters.
Re:Dplython: Dplyr for Python by CurtHagenlocher on Tuesday March 22, 2016 @08:56AM (#11336162)
It looks like both Dplython and pandas-ply are missing one of (what I think is) the core value propositions of dplyr: the ability to use the same abstractions on local data and on remote data, with execution against the remote source happening lazily such that the entire table doesn't need to be downloaded in order to run a filter locally.

(Of course, I may be biased in that I work on a commercial product which also has this characteristic.)

Re:Dplython: Dplyr for Python by TheLogothete on Tuesday March 22, 2016 @09:14AM (#11336283)
What product?

edit: After some stalking, I see you work on PowerQuery. Great product! Improving the SQL editing capabilities would make it much better!

Re:Dplython: Dplyr for Python by capybara on Tuesday March 22, 2016 @11:18AM (#11337194)
Dplython developer here... Definitely a big and important next step. I wanted to get some feedback on the in-memory case first.
Re:Dplython: Dplyr for Python by tanlermin on Tuesday March 22, 2016 @11:38AM (#11337342)
Blaze has already spent alot of time on this usecase and seems quite promising for a whole host of other reasons. Perhaps it would be best to combine forces?

Also see this:

https://github.com/blaze/blaze/pull/484

Re:Dplython: Dplyr for Python by capybara on Tuesday March 22, 2016 @03:07PM (#11339112)
The idea of putting the column names into the namespace is very interesting, and blaze looks pretty promising overall as a way to connect to big data sources.
Re:Dplython: Dplyr for Python by tanlermin on Tuesday March 22, 2016 @09:26AM (#11336356)
Blaze for python does this