The unanimous response to my question "Why no 'use strict' in Python?" was: PyChecker. Thanks to everyone who pointed me to this excellent tool.
The first person to respond to my query was David Ascher, architect of ActiveState's Komodo. Why, I asked David, isn't PyChecker included with the standard Python kit, and accessible by way of a command-line switch? David's response (via email, quoted with permission1):
I suspect that it goes something like this:
- the parsing infrastructure was developed with two goals in mind: correctness and speed, and maintaining extra data that you'd need for doing linting wasn't high enough priority early on.
- the "right" way to do it is to use the new compiler system
- since pychecker "works", the incentive to do it right is only one that appeals to those people in pursuit of beauty for its own sake.
- Those guys are busy.
Another noteworthy comment on this subject comes from Ted Leung:
I don't know the history behind various Python features, so I can't comment on strict. What I can comment on is that strict is nice, but a type inferencer for Python would be better (as I've posted before). One of the reasons that I'm excited to be going to PyCon this year is Michael Salib, an undergraduate at MIT has written Starkiller, a type inference engine for Python. [Ted Leung on the air]
Fair enough. Based on the email I've been receiving, though, it's clear that I'm not the only Python programmer who's been unaware of PyChecker. Evidence suggests that it might deserve to be elevated to a command-line-accessible option.
1 Emails from Ross Mayfield, CEO of Socialtext, include a .sig that ends with:
this email is: [ ] bloggable [ x ] ask first [ ] privateGreat idea! I've added this to my own .sig.
Former URL: http://weblog.infoworld.com/udell/2004/03/06.html#a937