Upcoming v1.0.0 about dfply

[Make42]

Since you are changed quite a bit anyway for 1.0.0, maybe you can consider to use filter (as in dplyr) instead of mask? I am not sure why you deviated in this particular case, while kept to the verbs of dplyr otherwise.

Also: Could you include the option to filter based on the index?

FInally: Do you have an estimate for when the 1.0.0 version will come out?

[jankatins]

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, @singledispatch in python) to make the functions work with different inputs. Instead of doing if instanceof(input, Series): ... elif instanceof(input, GroupBy): ... else raise Error() you write a simple base functions which just raises NotImplementedError and decorate is with @singledispatch and 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]

I like both of those. I was trying to do something similar to the@singledispatch thing you're talking about with the new TypeAction class, but this sounds better in many ways. I will check out your prototype. I'll also see if it would be easy to put the non-standard evaluation functions in and redesign the internals to mimic this kind of functionality. Thanks for the tips!

[kieferk]

@JanSchulz I read over these and I definitely like the singledispatch/registration pattern for these verbs. I think this is a more elegant solution to the one I was building towards.

Maybe I'm being overly optimistic but I think that I could change the base code that deals with piping to fit into this framework without a huge amount of hassle. I just need to make sure it all plays nice with the symbolic X. Right now i have the selection helpers working in the feature/collapsed-selection branch, which was tricky to get working correctly. Not sure how it will go down with this setup until I test things out.

Regardless, I think your suggested pattern is the way to go because it is readable and easy to extend. With the winter holidays coming up in a week or two I am going to use that free time to try and change the implementation to match what you've laid out in your blog post.

[Make42]

Is 1.0.0 abandoned? Or why did you close the topic?

[sharpe5]

I'm also keen to know!