Steven D'Aprano wrote: > On 28/08/12 19:02, Peter Otten wrote: >> Personally, I'm a big fan of ducktyping, so I would probably remove the >> check completely and live with the consequences: >> >>>>> >>> pyprimes._validate_int = lambda x: None >>>>> >>> pyprimes.isprime_naive(8.5) >> True >> >> garbage-in, garbage-out -- so what. > > > Duck-typing means that if an object implements the interface for an int, > or if it behaves like an int (not quite the same thing!), you can safely > treat it as an int. > > 8.5 is not an int, and isn't a prime number, so why is isprime claiming > it is prime? That's a bug -- or rather, it *would* be a bug except you > deliberately broke it.
No, I demonstrated the limitations of an alternate implementation, one that I prefer in spite of these limitations. > There's a strong argument to be made that isprime should accept any > number and return False for those which aren't integers, rather than > raise an exception. That's reasonable behaviour. > > But silently returning garbage? That's the worst thing you could do, *far* > worse than an unexpected exception or an overly-strict type-check. Allowing floats for a primality test is a can of worms anyway. You will inevitably run out of significant digits: >>> from pyprimes import isprime_naive as isprime >>> 2**61-1 2305843009213693951 >>> isprime(2305843009213693951.0) False >>> isprime(2305843009213693951) True >>> int(2305843009213693951.0) 2305843009213693952 > Errors should occur as close as possible to where they are introduced, > and functions shouldn't return garbage -- they should either be correct, > or raise an exception. Returning some junk value is bad. Imagine if you > accidentally called len(None), and instead of raising, it returned 17. > That's how bad it is. > > > I'm reminded of this quote: > > > "I find it amusing when novice programmers believe their main job is > preventing programs from crashing. ... More experienced programmers > realize that correct code is great, code that crashes could use > improvement, but incorrect code that doesn’t crash is a horrible > nightmare." -- CD Smith I think it depends on what you expect from a function. If you want it to execute a particular algorithm it is OK not to impose limitations on the input. As a building block for an actual application I'd go with a whitelist and require a numbers.Integral or even int (assuming Python 3) instance. _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
