jankatins
commented
7 years ago just some food for thought from adding a small verb in tidr and what I liked about the dplyr/tidr implementation:
- The extensibility of single dispatch (=S3 system in R,
@singledispatchin python) to make the functions work with different inputs. Instead of doingif instanceof(input, Series): ... elif instanceof(input, GroupBy): ... else raise Error()you write a simple base functions which just raisesNotImplementedErrorand decorate is with@singledispatchand then add the rest of the functions for Series, GroupBy and so on. Extending the system for SQL backends is then "only" adding a functions for suitable wrapper around a SQL connection. I wrote a small protoype for it and still want to try it in dfply. - The strict split between "Non-standard-evaluation" (NSE -> all normal dplyr functions) and the SE variants (the functions with underscore), where the later are for "programming" and the former for "interactive" work (see https://cran.r-project.org/web/packages/dplyr/vignettes/nse.html). In the python world, it basically translates to: NSE functions do the stuff to get a list of columns and then call the SE functions with that list of columns. IMO the split of the decorator between "do all the work to get the list of columns" and the step of doing something with that list of columns made sense as it lets you "opt in" to some features: I like composability by explictly adding a decorator or (IMO even better) by calling a function.
kieferk
Make42
sharpe5
Hello users,
I have been working on and off on an upcoming version which will be v1.0.0 due to its incompatibility with previous versions. You can actually view this nearly-complete version in the "feature/collapsed-selection" branch.
Originally I was just working on getting the selection helper functions working, but in order to do that a lot had to change with the base decorators. The selection helper functions now work (such as
contains("ca")for finding columns that contain that string as an argument to the select function. Previously, there were a variety of different decorators that would be stacked together to get different kinds of behavior. In the new conceptualization, the only decorator that will be used is the@dfpipedecorator and it will take keyword arguments that can change its behavior (it can also be used without keyword arguments in which case it will behave as the current@dfpipedecorator does now.If you're interested in checking it out and have any questions/comments/concerns, please go ahead. I don't have a timetable for its release but considering it's nearing completion and currently passes all the written unit tests, I don't expect it will be much longer.