Tim, I've seen a couple of checkins lately from you like this:
Modified Files: random.py robotparser.py Log Message: Whitespace normalization.
Apparently you watch checkins to the std library and run reindent on changed modules occasionally. Would it make sense to check in a test case into the test suite that verifies that all std modules are reindent fixpoints, so that whoever changes a module gets a chance to catch this before they check in? --Guido van Rossum (home page: http://www.python.org/~guido/)
Your @Home email is working?! I'm back on MSN. @Home is up, but times out on almost everything for me.
I've seen a couple of checkins lately from you like this:
Modified Files: random.py robotparser.py Log Message: Whitespace normalization.
Apparently you watch checkins to the std library and run reindent on changed modules occasionally.
I run reindent on *all* std Library modules once or twice a week: if a file is a reindent fixed-point, reindent leaves it entirely alone, so no spurious checkins are generated. That is, reindent saves "before" and "after" versions of the entire module in memory, and doesn't even write a new file if before == after.
Would it make sense to check in a test case into the test suite that verifies that all std modules are reindent fixpoints, so that whoever changes a module gets a chance to catch this before they check in?
Don't think it's worth the bother: running reindent over everything in Lib/ takes well over 10 seconds on my 866MHz box, so it would end up getting skipped by people anway. More suitable for an infrequent cron job, yes?
I've seen a couple of checkins lately from you like this:
Modified Files: random.py robotparser.py Log Message: Whitespace normalization.
Apparently you watch checkins to the std library and run reindent on changed modules occasionally.
I run reindent on *all* std Library modules once or twice a week: if a file is a reindent fixed-point, reindent leaves it entirely alone, so no spurious checkins are generated. That is, reindent saves "before" and "after" versions of the entire module in memory, and doesn't even write a new file if before == after.
Would it make sense to check in a test case into the test suite that verifies that all std modules are reindent fixpoints, so that whoever changes a module gets a chance to catch this before they check in?
Don't think it's worth the bother: running reindent over everything in Lib/ takes well over 10 seconds on my 866MHz box, so it would end up getting skipped by people anway. More suitable for an infrequent cron job, yes? BTW, there are still many Python files in the std distribution that haven't been run thru reindent yet. For example, I'm uncomfortable doing anything in Lib/plat-irix6, etc: don't have the platform, and no test suite anyway. Put out a call for others to clean up directories they care about, but nobody bit.
Tim> Don't think it's worth the bother: running reindent over everything Tim> in Lib/ takes well over 10 seconds on my 866MHz box, so it would Tim> end up getting skipped by people anway. More suitable for an Tim> infrequent cron job, yes? On Unix at least, you could simply eliminate it from the quicktest target to speed up most test runs. Dunno how you'd avoid executing it on other platforms. S
participants (3)
-
Guido van Rossum -
Skip Montanaro -
Tim Peters