fix *toolz links in README.rst

Thanks @amontalenti !
Faster `remove` by using `filterfalse`, which was added to `compatibility`

Also, a typo (it lied!) was fixed in the documentation of `remove`

By using `filterfalse`, we modify the behavior of `remove` when `None` is
used as the predicate.  Previously, `remove(None, [0, 1, 2])` raised
`TypeError`.  Now it returns `[0]`.  If we want the former, we can add a
check for `None`.
Merge pull request #177 from eriknw/faster_remove

Faster `remove` by using `itertools.filterfalse`, which was added to `compatibility`
Faster unique, isdistinct, merge_sorted, and sliding_window.

The `key` keyword argument to `unique` was changed from `identity` to `None`.
This better matches API elsewhere, and lets us remove `identity` from being
redefined in `itertoolz`, which always seemed a little weird.

Most of the speed improvements come from avoiding attribute resolution in
frequently run code.  Attribute resolution (i.e., the "dot" operator) is
probably more costly than one would expect.  Fortunately, there weren't
many places to apply this optimization, so impact on code readability was
minimal.

`unique` employs another optimization: branching by `key is None` outside the
loop (thus requiring two loops).  While this violates the DRY principle (and,
hence, I would prefer not to do it in general), this is only a few lines of
code that remain side-by-side, and the performance increase is worth it.

`merge_sorted` is now optimized when only a single iterable remains.  This
makes it *so* much faster while in this condition.
Faster groupby!

Issue #178 impressed upon me just how costly attribute resolution can
be.  In this case, `groupby` was made faster by avoiding resolving the
attribute `list.append`.

This implementation is also more memory efficient than the current
version that uses a `defaultdict` that gets cast to a `dict`.  While
casting a defaultdict `d` to a dict as `dict(d)` is fast, it is still
a fast *copy*.

Honorable mention goes to the following implementation:
```python
def groupby_alt(func, seq):
    d = collections.defaultdict(lambda: [].append)
    for item in seq:
        d[func(item)](item)
    rv = {}
    for k, v in iteritems(d):
        rv[k] = v.__self__
    return rv
```
This alternative implementation can at times be *very* impressive.  You
should play with it!
Merge pull request #175 from mrocklin/fix-readme-links

fix *toolz links in README.rst
add links to google group and cytoolz
Add useful code comments to groupby including pythonic implementation
add community section
add cython link
Small tweak to `groupby` to improve it for "real-world" data

Benchmarks have a tendency to use data that is pathologically perfect.
In such pathological cases, it was unclear whether the current or previous
implementation would be preferred.  However, when the input data gets
shuffled, the implementation in this commit is *clearly* superior.
Therefore, I believe this is the best implementation for *real* data.
Add a new implementation of `groupby` that uses two dicts.

The previous commit was wrong.  It is slower than the commit before.
There was a mistake in the code used for benchmarks.

I believe the new implementation has optimal performance as groups
get larger.  It is also fast when creating a new group.  It is slowest
when each group has two or three items in it, but it is still fast
enough so as to not impact the general performance of the algorithm.

A note on size: using a second dict in the implementation doesn't
add much memory.  Let us consider the size used by all of the
containers--dicts and lists--but not their contents.  For the worst
case scenario in which both dicts have two items (note that `fastdict`
only has groups of length two or greater), memory usage is only
increased by about 25% by having a second dict.
No need to import `compatibility.iteritems` in `itertoolz`
Choose a version of `groupby` that is easier to understand.

This is `groupby_alt` from the original commit comment in this branch.
See discussion at #179.  This version performs very well as groups become
larger.  The previous implementation performs well when 10% or more of
the elements form groups of length one.

We plan to have various implementations in `benchmarkz` repository, which
will let contributors add benchmarks that they care about and easily run
them on all variants of `groupby`.
Fix minor typo in composition.rst
Merge pull request #182 from njwilson/patch-1

Fix minor typo in composition.rst
Merge pull request #180 from mrocklin/readme-links

add links to google group and cytoolz
Merge pull request #178 from eriknw/faster_unique

Faster unique, isdistinct, merge_sorted, and sliding_window.
Merge pull request #179 from eriknw/faster_groupby

Faster groupby!
first draft of left join