len() should always return something

[Steven D'Aprano]

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