[Python-Dev] When to signal an error

[Guido van Rossum]

(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/)