Donald Stufft writes:
Working on the Python stdlib is somewhat frustrating to me in this regard because the code in the stdlib is often times wildly inconsistent even within the same module.
Maybe you haven't paid attention to past discussions, but the Python stdlib is a terrible example because fixing it up is a FAQ on this list, on core-mentoriship, and (in the past) on python-dev. It has been repeatedly vetoed on the grounds that changes, even in whitespace, are likely to introduce more bugs than consistent style is worth. If you're actually working *on* the stdlib, then improve the style as you fix bugs or add features. If you are working on something that requires studying the stdlib, then you're out of luck. None of the above means that improving the stdlib's coding style is off the table as far as I'm concerned. I personally wouldn't mind seeing it happen, but I don't care that much. What it means is simply that the stdlib is the worst possible example to make your case -- everybody agrees with you about the inconsistent style, but Those Who Make Decisions Around Here think there are more important considerations than style.
I was merely offering my experience that *anything* which relies on a human to verify it is, without exception, going to be verified unevenly and that using a human to verify it invites people to attempt to argue against it more often than when a machine does it.
But the stdlib is a terrible example for that purpose for the same reason. But I take your point that using a machine can smooth correction of "mechanical" errors. Mine is simply that I don't see that it makes such a big difference in my experience; most people who have horrible coding styles respond to human advice quite well, and the "minor" differences are -- minor. YMMV.