> But what about similar-looking functions with similar functionality? Even though we're unlikely to need this construction more than once: def is_prime(x

> But what about similar-looking functions with similar functionality? Even though we're unlikely to need this construction more than once: def is_prime(x): return x in primes(x) This one (or one just like it) appears quite common: def is_in_set(x,y): return x in y But Guido already noticed that! That's why he made an "in" operator in the first place! As soon as our routines become too generic, we're just making APL without arrays, and that's why taste matters so very much. > That promise is the same as "code-hiding". If I can see the implementation at the same time as its usage, then the code is not hidden. Ipso facto. But to expand more on what I mean by this, consider that close() is hiding code: You get all of the bugs in the C library; in the Kernel; all in code you cannot see either because it is locked/compiled, or because it's in a different file you didn't bother to read. And so on. And yet the world didn't stop spinning, and many people use close() every day without knowing or dealing with a myriad of bugs and weird corner cases[1]. So it is that even if code hiding is sometimes bad, it is sometimes less bad than other things we could be doing. [1]: Ha ha, only serious. http://geocar.sdf1.org/close.html http://geocar.sdf1.org/close.html