[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