[Python-Dev] When to signal an error (original) (raw)

Guido van Rossum guido@python.org
Fri, 18 Jan 2002 22:38:56 -0500

(I'm changing the topic :-)

At runtime, Python tends to complain about iffy situations, even situations that other languages might silently accept.

"Other languages" being Perl or JavaScript? The situations you show here would all be errors in most languages that are compiled to machine code.

For example:

print 50 + " percent" # TypeError x = [1, 2, 3]; x.remove(4) # ValueError x = {}; print x[3] # KeyError a, b = "x,y,z,z,y".split() # ValueError x.append(1, 2) # TypeError, recently print u"\N{EURO SIGN}" # UnicodeError I'm not complaining. I like the pickiness.

That's why you're using Python. :-)

But the Python compiler (that is, Python's syntax) tends to be more forgiving. Examples:

- Inconsistent use of tabs and spaces. (Originally handled by tabnanny.py; now an optional warning in Python itself.) - Useless or probably-useless expressions, like these: def g(f): os.environ['EDITOR'] # does nothing with value f.write(xx), f.write(yy) # should be ; not , f.close # obvious mistake (PyChecker catches the last one.) - Non-escaping backslashes in strings (there is a well-known reason for this one; but the reason no longer exists, in new code anyway, since 1.5.) So we catch things like this with static analysis tools like tabnanny.py, or lately PyChecker. If Guido finds any of these syntax-checks compelling enough, he can always incorporate them into Python whenever (but don't hold your breath). Again, you'll get no complaints from me on this. But I am curious. Is this apparent difference in pickiness a design choice? Or is it just harder to write picky compilers than picky libraries? Or am I seeing something that's not really there?

There's no unifying reason why thes examples are not errors. The first and last can be considered historical raisins -- the tabs/spaces mix was considered a good thing in the days when Python only ran on Unixoid systems where nobody would think about changing the display size for tabs; we know the reason for the last. But it's hard to change these without inconveniencing users, and there are other ways to deal with them (like picky tools).

The three examples in the second item have in common that they are syntactically expressions but are used in a statement context. The problem here that any language designer is faced with: you would want to allow expressions with an obvious side-effect, but you would want to disallow expressions that obviously have no side-effects. But where to draw the line? Traditional parsing technology such as used in Python makes it hard to be very differentiating here; a good analysis of which expressions "make sense" and which ones don't can only be done during a later pass of the compiler.

I believe that evertually some PyChecker-like technology will be incorporated in the Python compiler. The same happened to C compilers: the lint program became useless once GCC incorporated the same technology.

But these warnings will always have a different status than purely syntactical error: there are often cases where the user knows better (for example, sometimes an attribute reference can have a desirable side effect).

--Guido van Rossum (home page: http://www.python.org/~guido/)