Please consider backporting r59653 and r59654 to release25-maint branch.

It may be of interest to backport r52688 too, also, r63776 together with
r63914 (without these last two I get segfault when passing a list as an
option value).

Finally there is this issue4333 which wasn't committed anywhere, but if
it gets committed I would like to see it getting backported too.

Thanks.

I'm skeptical about backporting r59654. Doing so might break existing
applications.

Can you remind me what problem was fixed with r59653? I can't find the
Tk tracker anymore on which this apparently was reported.

If it fixes a problem with supporting Tcl 8.5, then I will also reject
the request. Supporting Tcl 8.5 is a new feature, and should thus not be
added to 2.5.3. Only Tcl up to 8.4 is support by Python 2.5.

On Wed, Dec 10, 2008 at 6:15 AM, Martin v. Löwis <report@bugs.python.org> wrote:
>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> I'm skeptical about backporting r59654. Doing so might break existing
> applications.
>

I don't see in what way it would break existing applications. The
indices returned by that command in Tcl should all be represented as
strings in Python, so I see this at max causing a double attempt to
convert it to str.

On Wed, Dec 10, 2008 at 6:21 AM, Martin v. Löwis <report@bugs.python.org> wrote:
>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> Can you remind me what problem was fixed with r59653? I can't find the
> Tk tracker anymore on which this apparently was reported.
>

I had trouble finding it too, it was redirected to somewhere else and
marked as private because of spam. I asked a tk developer for the
issue and he kindly pasted the comments here:
http://paste.tclers.tk/1381?v=raw
I didn't want to go offtopic here but it raises a question about
handling bgerror and I don't know where else I should ask this so.. I
have been working on a new _tkinter (before I went traveling, back
now) and I have been supporting the use of bgerror but would like to
know what kind of problems it used to cause to Tkinter or _tkinter.
For IDLE specifically I had to disable it.

> If it fixes a problem with supporting Tcl 8.5, then I will also reject
> the request. Supporting Tcl 8.5 is a new feature, and should thus not be
> added to 2.5.3. Only Tcl up to 8.4 is support by Python 2.5.
>

But if it doesn't affect anything in the current usage, why not
backport such patch ? Even though you can say that tcl 8.5 is not
supported by python 2.5, _tkinter doesn't enforce this.

> I don't see in what way it would break existing applications. The
> indices returned by that command in Tcl should all be represented as
> strings in Python, so I see this at max causing a double attempt to
> convert it to str.

I can't quite follow your terminology: what indices?

I can imagine many cases where conversion using Python's str() gives
a different result than the conversion through Tcl objects. For example,
if Python returns a bool, 2.5 will pass 'True' to Tcl. 2.6 will convert
this to a Tcl boolean, whose string representation is '1'.

If you are saying that the Python command *should* return strings
always, then this assumption is precisely a candidate for breakage:
people might currently be returning all kinds of things to Tcl in
callbacks (even outside Tkinter), and we might break these
applications.

On Fri, Dec 12, 2008 at 9:06 PM, Martin v. Löwis <report@bugs.python.org> wrote:
>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
>> I don't see in what way it would break existing applications. The
>> indices returned by that command in Tcl should all be represented as
>> strings in Python, so I see this at max causing a double attempt to
>> convert it to str.
>
> I can't quite follow your terminology: what indices?
>
> I can imagine many cases where conversion using Python's str() gives
> a different result than the conversion through Tcl objects. For example,
> if Python returns a bool, 2.5 will pass 'True' to Tcl. 2.6 will convert
> this to a Tcl boolean, whose string representation is '1'.
>
> If you are saying that the Python command *should* return strings
> always, then this assumption is precisely a candidate for breakage:
> people might currently be returning all kinds of things to Tcl in
> callbacks (even outside Tkinter), and we might break these
> applications.
>

Are we talking about the same commit ? 59654 as in your original about
it breaking existing code.

> Are we talking about the same commit ? 59654 as in your original about
> it breaking existing code.

Oops, no. I now see that r59654 is fine for backporting. My last message
was about r59653, which probably does introduce backward compatibility
problems.

The other changes seem to introduce new features, so they are out of
scope.

I have backported r59654 as r67737. As indicated, the other patches are
not suitable for backporting.