This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients TFinley, mark.dickinson, rhettinger
Date 2009-01-07.20:06:22
SpamBayes Score 0.03558386
Marked as misclassified No
Message-id <1231358785.43.0.321946188952.issue4816@psf.upfronthosting.co.za>
In-reply-to
Content
1.  This is the most important issue.  Is the r>n case typically an
error in the user's program or thought process.  If so, then the utility
of a ValueError can be weighed against the utility of other cases where
you want combs/perms to automatically handle the r>n cases with an empty
output.  These use cases are what I'm mulling over this week.

2. I see your wikipedia link.  The one I was looking at was:
   http://en.wikipedia.org/wiki/Combination

3. I wasn't clear on the issue of explictness.  The potential problem
that it isn't immediately obvious to me what comb/perm does when r>n, so
if I see code that isn't explictly handling that case, I have to lookup
what comb/perm does do to make sure the code works.

In the math module, it is a virtue that math.sqrt(-1) raises a
ValueError.  In the cmath module, it is a virtue that it does not.  The
latter case is distinguished because the programmer has explicitly
requested a routine that can handle complex numbers -- that is a good
clue that the surrounding code was designed to handle the complex result.

4. Not too worried about this one.  Essentially the thought is that code
that wasn't designed with the r>n case in mind probably benefits from
having a ValueError raised when that condition is encountered.
   
5. This one bugs me a bit.  It is nice to have all the factorial   
formulas just work and not have a piecewise definition.

BTW, we don't really have a difference of opinion.  My mind is open.  I
aspire to pick the option that is the best for most users including
students and novice users.  The trick in language design is to
anticipate use cases and to understand that people have differing world
views (i.e. it is a perfectly reasonable point-of-view that taking n
things r at a time makes no sense when r is greater than n).

In choosing, there is some bias toward sticking the API as it was
released.  Changing horses in midstream always causes a headache for
some user somewhere.

Am still thinking this one through and will let you know in a week or
so.  I also want to continue to research into how this is handled in
other libraries and other languages.
History
Date User Action Args
2009-01-07 20:06:25rhettingersetrecipients: + rhettinger, mark.dickinson, TFinley
2009-01-07 20:06:25rhettingersetmessageid: <1231358785.43.0.321946188952.issue4816@psf.upfronthosting.co.za>
2009-01-07 20:06:24rhettingerlinkissue4816 messages
2009-01-07 20:06:22rhettingercreate