Paul Prescod:
[...] But I'm most confident of the theory that you snapped at one person in particular because of something he said.
Guido:
He harped at the same issue in three consecutive message without explaining his position.
Actually I was quite happy with the thread. At runtime, Python tends to complain about iffy situations, even situations that other languages might silently accept. 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. 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? ## Jason Orendorff http://www.jorendorff.com/