[Python-Dev] Making None a keyword (original) (raw)

Guido van Rossum guido@python.org
Fri, 26 Apr 2002 16:08:09 -0400


Sorry, this is the syntax department. I think you need to speak to Mr. Tester in room 104.

I think I'll continue arguing in my spare time. :)

> > Clearly extending this through to run-time would add a huge testing > > infrastructure that would need maintaining, but allowing people to > > add their own codes to the syntax-checker base might mollify them a > > bit about the prospect of future language change. > > > > Call it the PythOnGuard (TM) database. :-) - if your programs would > > break you'll be mailed before it's committed to production. > > Sounds like some kind of huge test suite. The problem is, there's > always something that breaks... :-( > OK. The hugeness of the test suite was precisely what made me stick to syntax. Do you think quality would benefit by an enlargement of the test suite to non-distributed code?

The quality of what? We need lots more test, probably 40% of the C code isn't covered by the test suite.

Couple it with a few polling buttons from "I wouldn't mind fixing this breakage" to "I'ma get my gun and come looking for you" and you might obtain a measure of resistance *from people whose code would actually be broken*. Clearly this should not necessarily be the arbiter of development, but it might allow you to tell people whose code hadn't broken so far to just PythOnGuard it and not complain until something did break.

I think it's too simplistic to expect much out of testing a large body of real life code. Much of the expected breakage only shows up when an application is run on real-life data. Maybe running PyChecker on a large body of code would be a good idea, except that then the code would first have to be made PyChecker-clean -- and that's a moving target.

Also good for news releases: "What breaks in this version?" (I can see Paul Rubin loving that one).

It's easy to list the things that could potentially break. It's usually impossible to find whether they are used in a particular body of code without running a thorough test suite for that code.

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