On Tue, Sep 23, 2014 at 11:26 AM, Stefan Behnel <stefan...@behnel.de> wrote: > Wolfgang Maier schrieb am 23.09.2014 um 18:38: >> While at first I thought this to be a rather irrelevant debate over module >> private vs public naming conventions, I now think the OP is probably right >> and renaming fractions.gcd to fractions._gcd may be a good idea. > > Making a public API private is rarely a good idea. It should be enough in > this case to document the behaviour. > > And, believe it or not, it actually is documented: > > https://docs.python.org/3.5/library/fractions.html#fractions.gcd
I don't think documentation is sufficient in this case. This is the kind of thing though that is easy to forget about if you haven't read the documentation recently. And with a function like gcd, one generally wouldn't expect to *need* to read the documentation. >> Googling for recipes to calculate the gcd using python brings up >> fractions.gcd as a general answer (like at stackoverflow: >> http://stackoverflow.com/questions/11175131/code-for-greatest-common-divisor-in-python) >> and it is not obvious for non-mathematicians to realize that it is NOT a >> generally acceptable solution. > > It is. Certainly for positive numbers, which clearly present the majority > of use cases. It's definitely the "normal" use case, wouldn't you say? > > For negative numbers, the "expected" behaviour seems to be unclear, so the > current behaviour is just as good as any, so backwards compatibility > concerns clearly win this fight. I'm not convinced it's all that clear. In addition to Mathworld and Wikipedia that were already cited, ProofWiki provides an actual proof that gcd(a, b) = gcd(|a|, |b|), by way of noting that a and |a| have the same factors. -- https://mail.python.org/mailman/listinfo/python-list