[Idle-dev] How does one offer patches?

Bruce Sherwood basherwo at ncsu.edu
Mon Oct 11 04:44:55 CEST 2010


Thanks much, Tal. There has already been extensive testing of VIDLE.
Guilherme's GSoC version was distributed under the name of VIDLE with
VPython 2.6 or 2.7 during the past year with no hint of problems. As
part of getting VPython to work with Python 3 I manually applied
Guilherme's patches to the Python 3 idlelib to make a Python 3 VIDLE
and the diff patch. I've been using Python 3 with VPython and VIDLE
for several weeks on Windows with no problems, and I've used VIDLE a
little on a Mac. However, I don't do anything fancy with VIDLE, so I
have no way of knowing whether there could be problems with some
features I don't use.

Again, I'm ignorant: How/where do I get "a recent SVN revision"? Would
it be any different from C:\Python3.1\Lib\idlelib? (I have Python3.1.2
installed.)

I don't feel competent to provide individual patches that are
feature-specific, because I haven't studied IDLE in any great depth
but rather concentrated just on getting Guilherme's work into the
latest Python 3 idlelib. But if I'm told how to get something more
recent than C:\Python3.1\Lib\idlelib I can produce a diff patch
against it, as one large diff.

A detail: Guilherme produced a "Revert" plugin, and the corresponding
file doesn't show up in the diff. How would I offer the new file?

Bruce Sherwood

On Sun, Oct 10, 2010 at 6:19 PM, Tal Einat <taleinat at gmail.com> wrote:
> Bruce Sherwood wrote:
>> Please forgive me for my ignorance, but how does one offer patches to
>> IDLE? At http://vpython.org/vidle/patch.diff is a patch from the
>> idlelib installed with Windows Python3.1.2 to vidle, where vidle
>> incorporates the work done in the 2009 GSoC by Guilherme Polo, updated
>> for Python 3. For details, see my posts of Sept. 14.
>>
>> I have several questions:
>>
>> 1) Is the idlelib shipped with Windows Python 3.1.2 the right base to
>> diff against?
>>
>> 2) If not, against what base should I make the diff?
>>
>> 3) Is one diff for all of idlelib okay, or does one submit separate
>> diff files for each file?
>>
>> 4) How/where do I formally offer this diff? I've never done this before.
>>
>> I should add that just today I remade the diff at
>> http://vpython.org/vidle/patch.diff because I discovered that I'd
>> missed an important correction Guilherme had made. The error is
>> present in the Python 3.1.2 idlelib. In IOBinding.py one should delete
>> this statement:
>>
>>     self.text.see("insert")
>>
>> Unless this statement is deleted, when you open a long file the first
>> line is not seen; it's above the edit display. This can be pretty
>> confusing.
>
> Since IDLE is part of the Python stdlib, patches (and bugs and
> features requests) should be posted on the Python bug tracker at
> bugs.python.org. For major patches such as this, a mention on the
> idle-dev mailing list is also helpful to get things moving along.
>
> A patch should contain all relevant changes to all relevant files.
> Ideally, a patch should encapsulate a single set of changes, and after
> applying it everything should still work as expected. If several
> unrelated changes have been made in VIDLE, it might be better to post
> a patch for each change separately to make testing and reviewing
> simpler. This can take a bit of work though, and it's better to post
> one big patch than to post nothing at all.
>
> Patches should preferably be based on a recent SVN revision. The more
> recent the better, but next point is more important...
>
> Patches should only be posted after having been well tested in order
> to avoid frustrating the reviewers. From my experience, posting a
> patch and later mentioning small fixes and edge-cases will often cause
> a patch not to be accepted, because nobody will want to review it.
> Posting a patch and requesting help in fixing a few last problems is
> okay, of course, as long as you've recognized the problems and mention
> them in advance.
>
> I hope this helps! I'm itching to get Guilhereme's changes in!
>
> - Tal Einat
>


More information about the IDLE-dev mailing list