> 5. This one bugs me a bit.  It is nice to have all the factorial
> formulas just work and not have a piecewise definition.

IIRC, in the 'Concrete Mathematics' book, Knuth and co use something
like

(n choose k) = (n-to-the-k-falling)/k!

to get around this:  this definition works for all k >= 0 and all
integers (or even real numbers) n.  Here x-to-the-k-falling means
x * (x-1) * ... * (x-k+1).  See:

http://mathworld.wolfram.com/FallingFactorial.html

> Another thought before I forget:  The piecewise definition of the
> choose function or for binomial coefficients suggests that
> supporting the r>n case should be accompanied by supporting 
> the r<0 case.

I'd say not:  in the context of sets of combinations/permutations,
(rather than just defining the nCr or nPr symbols) r has a
definite meaning as a cardinality:   "enumerate all subsets of
iter of cardinality r" and so it makes sense to me to restrict to
the case where r is nonnegative.

(If we were talking about the integer-valued function nCr, then I'd
agree.)

My own guess would be that having combinations(range(n), r)
give the empty iterator for r > n is the right thing in the
vast majority of situations, even (especially?) where the
programmer hasn't anticipated the possibility of r > n.
I have yet to see a case where it's useful to raise ValueError.

I have access to the Magma algebra package at work;  I'll
check tomorrow or Friday to see what that does.