[Python-Dev] IDLE patches - bugfix or not?

Kurt B. Kaiser kbk at shore.net
Wed Aug 16 04:53:55 CEST 2006


Anthony Baxter <anthony at interlink.com.au> writes:

> On Wednesday 16 August 2006 06:19, Jim Jewett wrote:
>> I just uploaded a series of IDLE patches, but I'm not quite sure how
>> to classify them on the feature/bugfix scale now that the last beta is
>> out.
>>
>> >From most to least buggish:
>>
>> python.org/sf/1540892 -- honor the new quit() behavior.  On the other
>> hand, it was documented that this didn't work in IDLE, and it is
>> *possible* that someone was counting on this.
>
> This seems like a sensible thing to add.
>
>> python.org/sf/1540851 -- with is now a blockopener, and should be
>> counted as such -- I *think* this one would be safe, but I know that
>> changing a parser can be surprising, and I suppose it *could* wait
>> until with no longer requires a future statement.
>
> If this can be done safely, it should be done. Preferably before RC1, so that 
> we have time to fix any issues it shows up.

I will look at these two.  RC1 seems reasonable.

>> python.org/sf/1540874 -- broken shortcut keys.  On windows, only one
>> entry per menu can be reached with the same shortcut letter, so
>> advertising others is just an attractive nuisance.  I'm not sure that
>> other systems wouldn't be able to use the hidden shortcuts.
>
> Tough call. I guess it depends on the other systems - I will try this on Linux 
> at least, and see if it works there. If it's broken everywhere, then changing 
> it would seem the least offensive choice.

I would have been inclined to make the other choice, i.e. 'p' as the
hotkey for print, rather than the rarely used "save copy as".

>> python.org/sf/1540869 -- GUI fix.  The current code puts in a
>> separator using a magic number (and has XXX comments about it.)  This
>> changes the magic number so that the separator is more visible, but
>> I'm not sure the old behavior rose to a bug, or that it wasn't
>> platform dependent.
>
> Let's leave this one for 2.6.
>
>> python.org/sf/1540849 -- except too broad.  I wouldn't suggest
>> applying this late in the release cycle, except that it seems sort of
>> like the memory errors that are still being patched.
>
> I'd be concerned that this might cause other obscure behaviour changes, and so 
> I'd prefer to leave this to 2.6.

Yes, 2.6 for these two.

-- 
KBK


More information about the Python-Dev mailing list