On Fri, Jul 13, 2018 at 10:43:12AM +0200, Jacco van Dorp wrote: > If there's going to be failure possible primality tests, there should > also exist certain ones. No matter how slow it can be to do it. > > Python if often a language for beginners. I think it'd be confusing to > a lot of people that there's going to be tests that show "This one is > probably prime", instead of sure tests.
I think that it is precisely because this will be used by beginners that we shouldn't offer such a choice. Its our job to curate the APIs in the std lib, not to burden inexpert users with excess choices that will only worry them. If this were a third-party module, I would say, "the more the merrier". Let it provide a dozen different implementations, that's cool. But the stdlib is batteries, not nuclear reactors. If you want a choice of algorithms, or the ability to configure space versus time versus guarantees, I think you ought to be using a 3rd party module, not the std library. I'm not saying hide the fact that it is probabilistic, but that's an implementation detail that *in practice* makes no difference at all. Using Miller-Rabin and 30 randomly chosen witnesses, the probability of a wrong answer is < 0.000000000000000001. If we tested a million numbers a second, it would take an average of 18,000+ years to come across a single such error. In comparison, your computer probably experiences something of the order of 1 cosmic-ray induced bit-flip causing data corruption per week. https://stackoverflow.com/questions/2580933/cosmic-rays-what-is-the-probability-they-will-affect-a-program Since using probabilistic methods is good enough for PGP and other high-security protocols, it's surely good enough for Tom Schoolboy testing whether 1234567890123456789 is prime. (For the record: it isn't.) -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/