Add filtering joins, tests

[bleearmstrong]

semi_join() and anti_join() are now functional, and there is a fair bit of testing added for them.
One possibly minor note: they do require pandas v. 0.17.0 (current on v. 0.18.1). Not sure if this is too much to ask, but they do require it (specifically, it's an option that was added to pandas.DataFrame.merge).

[bleearmstrong]

I've since added gather() from tidyr. Technically not dplyr, but the tidyr package (it only has a few functions) may be nice to add, since it plays well with dplyr.

[bleearmstrong]

gather doesn't seem to play well with python 2.7.9 so I need to fix that first.

[dodger487]

Hey-- do you want to split this out into two pull requests? One request to add semi_join and anti_join, and a separate request (when you feel it's ready) for gather?

I agree with you that the main tidyr verbs would be awesome to have here. I think it makes sense to have them in this package.

[bleearmstrong]

I think it's kind of weird that github keeps adding commits to the pull request. It seems to me like it should freeze the request for when it was made.
What is the usual practice for that then? Check out that commit to a new branch and do a request then?

[dodger487]

I'm not an expert, but the methodology that I've been using that's worked well is what you describe. I keep all pull requests, and really any modular work like a new feature, in separate branches. I submit a pull request when that feature is ready, and only commit to that branch if I need to update something for the PR.

[has2k1]

@bleearmstrong, the common practice regarding pull requests is

1. You (a contributor) makes a pull request.
2. Other contributors (or maintainer) review and give feedback.
3. You make commits to address the feedback.
4. Maybe repeat steps 2-3 more times.
5. Pull request gets merged.

A pull request puts up a branch (and any subsequent additions to it) for review.

[bleearmstrong]

Thank you @has2k1, that makes sense when you explain it like that.