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 steven.daprano
Recipients FR4NKESTI3N, josh.r, kellerfuchs, mark.dickinson, rhettinger, serhiy.storchaka, steven.daprano, tim.peters
Date 2019-01-28.22:41:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20190128224130.GD1834@ando.pearwood.info>
In-reply-to <1548676121.7.0.790455104605.issue35431@roundup.psfhosted.org>
Content
> This involved a few changes, which seem to reflect the consensus here:
> - raise ValueError if k>n ;
> - rename the function to math.combinations.

I see at least four people (myself, Raymond, Mark and Tim) giving comb 
as first choice, and I didn't see anyone give combinations as their 
first choice.

I don't object to you taking it upon yourself to go with the longer name 
(which is my second choice), but I do object to you claiming concensus 
for the change without evidence of such.

> There was also no reply to my comment about `comb` being confusing 
> (due to the collision with an English word).

To be honest, I didn't think that comment needed a reply.

Collisions between words in different knowledge domains are not unusual. 
I don't think people think that math.tan has anything to do with 
changing the colour of their skin, or math.sin is about being wicked. 
Due to their length, permutation, combination and factorial are 
frequently abbreviated to perm, comb, fact and anyone looking for those 
functions should recognise the abbreviations.

But given the precedent set by itertools and math.factorial, perhaps you 
are right and we ought to stick to the longer name.
History
Date User Action Args
2019-01-28 22:41:38steven.dapranosetrecipients: + steven.daprano, tim.peters, rhettinger, mark.dickinson, serhiy.storchaka, josh.r, kellerfuchs, FR4NKESTI3N
2019-01-28 22:41:36steven.dapranolinkissue35431 messages
2019-01-28 22:41:36steven.dapranocreate