Hi Raymond, thanks for your well reasoned and thorough reply.  Just a
couple small thoughts... I'll borrow your numbers if you don't mind.

1. I'd ask you to discount this argument.  There are many situations in
the Python library where empty results are possible return values. 
There are likewise many places in mathematics where a set as defined
winds up being empty.  And sure, absolutely, sometimes this empty result
will be an error condition.  However, right off the top of my head, I
can't really think of any other place in the Python library where an
empty returned iterator/list is automatically assumed to necessarily be
an error.

The closest I can think of right now might be key/index errors on dicts
and sequences... but that's a user explicitly asking for exactly one
element, in which case non-existence would be bad.

In a larger sense, if a result computed by a function is sensible and
well defined in itself, it doesn't seem even possible for a function to
anticipate what answers might be considered error conditions by calling
code.  Potentially any return value for any function might be an error
for some user code.  So... the question then becomes, is the empty
result a sensible and well defined answer.  And here we differ again I
see.  :D

2. OK on perms.  If you don't mind, I'm going to talk about combinations
since that was my real motivation.

    Also see the wikipedia article on combinations (the
    "choose" function) which also expresses a factorial
    formula that fails for r>n. No mention is made for
    special handling for r>n.

Hmmm.  Are you looking at the definition of "choose function" under
Wikipedia?
     http://en.wikipedia.org/wiki/Choose_function
Notice the material after the "and," after the first part of the
definition, in case you missed it in your first reading.  So, this is
the def I was taught through high school and undergrad, perhaps the same
for Mark judging from his reply.  You were taught it was undefined?  It
does sort of complicate some other defs that rely on binomial
coefficients though, I'd think, but I guess you could make those work
with little effort.  It's not as though subtly different but
incompatible definitions of basic terms are that uncommon in math...
never knew the binomial coef was in that category though.  You teach
stats I take it?  I suppose you'd know then... never heard of it, but
that doesn't mean much.  Oh well.  (You can perhaps feel my pain at
seeing the current behavior, given my understanding.)

3. For your "replacement" myperm (let's say mycomb), if you insert a
"pool=tuple(iterable)" into the beginning, you'll have my fix, statement
for statement.  You advance this as desirable, while to my eye it was
nasty enough to motivate me to submit my first patch to Python.  So, you
can imagine we have a slight difference of opinion.  ;)  Let's see if I
can't present my view effectively...

Saying the fix is more explicit suggests there's something implicit
about the concise solution.  If the choose function is defined for those
values, then itertools.combinations is just unnecessarily forcing code
to treat something as a special case even when it's not.  So, I'd be
careful to draw a distinction between "more verbose" and "more explicit."

4. Can't really speak to that.  It's probably worth changing
documentation in any event, even if you reject the patch.  The provided
equiv code and the actual behavior in this "error case" differ anyway as
you noted in your second reply.  Also, this error condition isn't
evident from the documentation without reading and parsing the source code.

A third and extraneous comment, if you do wind up changing the docs
anyway, perhaps a shorter recursive solution would be easier to
understand?  Maybe it's just me since I'm sort of a functional type of
guy, but I found the equivalent code a little hard to parse.

5. Yeah.  Actually, I'm pretty sure that's why the choose function is
defined piecewise, since negative factorials are undefined as you say.