classification
Title: (Tkinter) Please backport these
Type: Stage:
Components: Tkinter Versions: Python 2.5.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: gpolo, loewis
Priority: release blocker Keywords:

Created on 2008-11-18 00:41 by gpolo, last changed 2008-12-13 15:06 by loewis. This issue is now closed.

Messages (9)
msg75995 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-11-18 00:41
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.
msg77489 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-10 08:15
I'm skeptical about backporting r59654. Doing so might break existing
applications.
msg77490 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-10 08:21
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.
msg77665 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-12-12 12:09
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.
msg77666 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-12-12 12:35
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.
msg77692 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-12 23:06
> 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.
msg77697 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-12-12 23:56
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.
msg77699 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-13 00:13
> 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.
msg77743 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-13 15:06
I have backported r59654 as r67737. As indicated, the other patches are
not suitable for backporting.
History
Date User Action Args
2008-12-13 15:06:20loewissetstatus: open -> closed
resolution: fixed
messages: + msg77743
2008-12-13 00:13:53loewissetmessages: + msg77699
2008-12-12 23:56:11gpolosetmessages: + msg77697
2008-12-12 23:06:21loewissetmessages: + msg77692
2008-12-12 12:35:39gpolosetmessages: + msg77666
2008-12-12 12:09:48gpolosetmessages: + msg77665
2008-12-10 08:21:41loewissetmessages: + msg77490
2008-12-10 08:15:14loewissetnosy: + loewis
messages: + msg77489
2008-12-04 17:24:21gpolosetpriority: release blocker
2008-11-18 00:41:32gpolocreate