Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Tkinter) Please backport these #48592

Closed
gpolo mannequin opened this issue Nov 18, 2008 · 9 comments
Closed

(Tkinter) Please backport these #48592

gpolo mannequin opened this issue Nov 18, 2008 · 9 comments

Comments

@gpolo
Copy link
Mannequin

gpolo mannequin commented Nov 18, 2008

BPO 4342
Nosy @loewis

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-12-13.15:06:20.581>
created_at = <Date 2008-11-18.00:41:32.359>
labels = ['expert-tkinter', 'release-blocker']
title = '(Tkinter) Please backport these'
updated_at = <Date 2008-12-13.15:06:20.580>
user = 'https://bugs.python.org/gpolo'

bugs.python.org fields:

activity = <Date 2008-12-13.15:06:20.580>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = <Date 2008-12-13.15:06:20.581>
closer = 'loewis'
components = ['Tkinter']
creation = <Date 2008-11-18.00:41:32.359>
creator = 'gpolo'
dependencies = []
files = []
hgrepos = []
issue_num = 4342
keywords = []
message_count = 9.0
messages = ['75995', '77489', '77490', '77665', '77666', '77692', '77697', '77699', '77743']
nosy_count = 2.0
nosy_names = ['loewis', 'gpolo']
pr_nums = []
priority = 'release blocker'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue4342'
versions = ['Python 2.5.3']

@gpolo
Copy link
Mannequin Author

gpolo mannequin commented Nov 18, 2008

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 bpo-4333 which wasn't committed anywhere, but if
it gets committed I would like to see it getting backported too.

Thanks.

@gpolo gpolo mannequin added the topic-tkinter label Nov 18, 2008
@gpolo gpolo mannequin added the release-blocker label Dec 4, 2008
@loewis
Copy link
Mannequin

loewis mannequin commented Dec 10, 2008

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

@loewis
Copy link
Mannequin

loewis mannequin commented Dec 10, 2008

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.

@gpolo
Copy link
Mannequin Author

gpolo mannequin commented Dec 12, 2008

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.

@gpolo
Copy link
Mannequin Author

gpolo mannequin commented Dec 12, 2008

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.

@loewis
Copy link
Mannequin

loewis mannequin commented Dec 12, 2008

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.

@gpolo
Copy link
Mannequin Author

gpolo mannequin commented Dec 12, 2008

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.

@loewis
Copy link
Mannequin

loewis mannequin commented Dec 13, 2008

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.

@loewis
Copy link
Mannequin

loewis mannequin commented Dec 13, 2008

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

@loewis loewis mannequin closed this as completed Dec 13, 2008
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

0 participants