On Sat, 25 Jul 2009 10:03:58 +0200, Piet van Oostrum wrote: >>S> And there's nothing ambiguous about len(42). > > len(42) should be 7.5 million.
And "I don't understand your reasoning".upper() should be "Millennium Hand and Shrimp!". Every function would be ambiguous if we treat it as returning an arbitrary result. But we don't -- semantics do matter. We expect that string.upper() should return the string converted to uppercase, and that's not ambiguous because we already know what uppercase means. Even if somebody didn't know what uppercase meant, they would expect that it had a meaning, and it was just a matter of learning what it meant: for example, one might take string.upper() as any of: * convert every letter a..z to A..Z * convert the first letter of each word to A..Z * throw away the argument and return the literal "upper" * count how many characters are in A..Z and so forth. These are some of the infinite number of *possible* meanings to string.upper(), but only one of them is the *actual* meaning. The method isn't ambiguous, because the language designers have chosen one meaning, and having learned what that meaning is, it's the *only* meaning you can legitimately use. If you (generic you) are uncertain what that meaning is, that's uncertainty, not ambiguity. Similarly, we might be uncertain about the meaning of len(42) -- reasonable values it might return are 0, 1, 2, the number of bits in 42, and possibly even 7.5 million as you suggest. But that's our ignorance, due to the fact that we haven't yet agreed on a meaning to len(42), and not ambiguity: having made up our mind what len(42) should mean, it could only mean one thing. However, mixed string/integer addition is a good example of ambiguity. We can add strings: "1" + "2" => "12" and we can add integers: 1 + 2 => 3 but it is ambiguous as to what "1" + 2 should return. Guido might have made Python behave like Perl, and define addition of a string and an int, but there would still be ambiguity in the expression, because we can't tell if the coder intended "1"+"2" and forgot to quote the two, or intended 1+2 and forgot to convert the string "1" to an int. Ambiguity essentially boils down to being unable to reasonably predict the expectation of the coder. I say "reasonably", because if you allow unreasonable situations, everything is "ambiguous": I typed: x = 42 + y but maybe I intended to import the math module, therefore the + operator is ambiguous. Reasonable? No, because we're allowed to assume the coder is rational, and mistakes are small. -- Steven -- http://mail.python.org/mailman/listinfo/python-list