This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients
Date 2002-09-10.04:57:30
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=80475

In the interests of saving time and having maximum 
accuracy, I recommend reverting and then re-applying first 
patch and then making the changes on my list.  Try not to 
make any other changes.

It took half a day to thoroughly review that 6000 line diff.  
It doesn't make sense for me to re-check everything from 
scratch. To keep the integrity of the review, make as few 
changes as possible.  

Also, it does make sense for you to give a self-review to 
your final diff (remember, GvR believes in public floggings 
for those who break working code).

Here are a couple of fast checks:
-- scan the diff for ''.join and make sure it came from a join
(strdata, "")
-- grep the final files for >= 0: or < 0: to see if the 'in' 
operator applies.
-- grep the final files for expand( to make sure an 
expandtabs( was not missed.
-- grep the final files for join("\n"), join(" "), or join(' ') to see 
if there was an error moving the separator to the front

A slower self check is to read the diff file line-by-line and 
mentally recompute each change and compare with the 
actual change.   The diff review will certainly catch 
unintended changes like the merge conflict or the she-
bang change.

I know you can't run each script, but do as much as you 
can by importing each script to see if it gets a compilation 
error.  This won't catch runtime errors but it will catch 
syntax glitches.

One important group of scripts can be run.  Try to give 
IDLE a thorough exercise.

Then, when you're feeling brave, commit.

Good luck!
History
Date User Action Args
2007-08-23 15:13:47adminlinkissue572113 messages
2007-08-23 15:13:47admincreate