Kaz Kylheku wrote: > You can have statically typed languages with inadequate type safety, > and you can have dynamically typed languages with inadequate type > safety.
But the point in this example was that the Java program ironically had the bug *because* Java handles ints in a type-safe way, while Python does not. >> What's better about the Python version? First, it will operate on >> *any* sorted array, no matter which type the values have. > > Uh huh! With hard-coded < and = operators, how stupid. What if you > want to use it on strings? > Would that be a case-insensitive lexicographic comparison, or > case-insensitive? How do you specify what kind of less-than and equal > you want to do? Where's the problem? The function uses the standard ordering of the values you feed to it, i.e. case-insensitive lexicographical order if you feed a lis of ordinary tuples of strings. You can also feed objects with a different ordering, like case-insensitive. Anyway, that was completely not the point. The point was that you could take that Java program, convert it directly to Python, and have automatically eliminated a bug. I did not claim that the resulting Python program was automatically a real good and Pythonic one. > -1 to indicate not found? Why copy Java braindamage induced by an > antiquated form of static typing? The Java version has to do that So you would call Python's str.find() method braindamaged as well? But as I said, that was not the point here anyway. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list