Backporting Idle patches from 3.x to 2.7 would be easier with a canned edit script. Below are the substitutions I can think of immediately. Do any of you know of others?

Easy (str.replace):
tkinter -> Tkinter
import tkinter.messagebox as tkMessageBox -> import tkMessageBox

A bit tricky (but still use str.replace):
OSError -> IOError
This presumes that IOError become OSError in 3.3 as well as 3.4 (#18151). But there are a few existig OSErrors is 3.3 (and that pre-existed the change in 3.4). So there would would need to be a check that a changed line matched an existing 2.7 line.

Harder (2to3 parser?):
print(arglist) -> print arglist  # but what if keyword args?
Outputting "fix print on line nn" would be easiest.

README needed (python -m) test -> (python -m) test.regrtest in the test instructions, but this should be the only place that occurs.

I might put 'edit_patch' or whatever in idle_test.

Are you planning to use this on the patches instead of using "hg graft"?
These things should be easy to fix during the 3-way merge, so I'm not sure if it's worth adding a specific script.  If you think it's necessary, consider making it a mercurial extension that can be run automatically during the graft.

Ezio: yes. Once I have written a working-directory diff to a file for upload (non-trivial on Windows), 'Import' is as easy to use as Graft and as far as I know, the result when successful is the same. I know I 'should' learn to use kdiff3 effectively, but it seldom works right for me, and the live repository is the wrong place to learn by failure. (This gives me an idea for another forum.)

A third always correct import substitution pair:
import tkinter.simpledialog as tkSimpleDialog <-> import tkSimpleDialog

I am not sure if a script will be used until I try one. I do not know anything about writing extensions. A lists of Idle-specific conversions may be enough.

> 'Import' is as easy to use as Graft and as far as I know, the result 
> when successful is the same.

I use import while importing patches from the tracker, but once I committed on 2.x it's easier to just graft instead of importing again (importing often requires you to generate a new patch and possibly you have to commit manually again after the import).

> I know I 'should' learn to use kdiff3 effectively, but it seldom works
> right for me,

That's what learning it is supposed to avoid :)

> and the live repository is the wrong place to learn by failure.

As long as you check the result before pushing there shouldn't be any problems.  If the merge goes wrong you can always rollback and try again (or try a different approach).  You can also use "hg diff -c tip" to see the diff of the last commit.

I am not sure what you mean by 'rollback'. My experience and understanding is that once I start a merge, I must finish it somehow before doing anything else. Do you mean revert a particular problematic file (like NEWS), and hand edit?

Another backport item. test.support <-> test.test_support.