Patches item #869468, was opened at 2004-01-02 10:22
Message generated for change (Comment added) made by david_ascher
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: David Ascher (david_ascher)
Assigned to: David Ascher (david_ascher)
Summary: Allow use of embedded Tcl without requiring Tk

Initial Comment:
Two things:

1) docstrings added to most attributes of the _tkinter 
app object


2) allow the user to create Tkinter.Tcl objects which are 
just like Tkinter.Tk objects except that they do not 
initialize Tk.  This is useful in circumstances where the 
script is being run on machines that do not have an X 
server running -- in those cases, Tk initialization fails, 
even if no window is ever created.

I'll be glad to discuss the implementation choices.

This has been tested on Windows, Linux, and Solaris.

I'm hoping to figure out how to attach the test file as 
well.  I don't have any documentation patch -- I'm 
willing to contribute one, but given the state of Tkinter 
documentation am not sure where to start...



----------------------------------------------------------------------

>Comment By: David Ascher (david_ascher)
Date: 2005-07-26 15:50

Message:
Logged In: YES 
user_id=6114

I'm fine w/ the proposed fix.  I don't recall the reason for
the delegation, but the proposed logic seems fine. 
Apologies for the bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-07-24 16:32

Message:
Logged In: YES 
user_id=6380

There seems to be a problem with this patch. It introduces
__getattr__, __hasattr__ and __delattr__ methods, which
attempt to delegate attributes to the self.tk object if they
aren't defined on self. This is fine for __getattr__.
__hasattr__ is based on a misunderstanding; there is no
special __hasattr__ method. Butthe real problem is
__delattr__ -- remember the asymmetry between __getattr__
and __setattr__? __getattr__ is only called as a fall-back
(when the attribute isn't found using the normal attribute
search), but __setattr__, if defined, is *always* called.
Well, __delattr__ behaves the same way as __setattr__. The
end result is that if someone sets a private attribute on a
Tk() instance, it can be set (because __setattr__ is not
defined) cannot be deleted (because __delattr__ is).

Why do I care? It breaks Tkdnd! Tkdnd stores a private
attribute (__dnd) on the Tk() object to indicate that it is
active, and deletes it to indicate that it is no longer active.

The fix is easy from my perspective: just get rid of the
__hasattr__ and __delattr__ methods. But I'd like to ask the
author and reviewer of the patch if they remember why this
delegation was added in the first place, and if there's
something that might be broken by my proposed fix.

----------------------------------------------------------------------

Comment By: David Ascher (david_ascher)
Date: 2004-02-17 22:03

Message:
Logged In: YES 
user_id=6114

Checked in.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-01-04 09:21

Message:
Logged In: YES 
user_id=2772

I think that "package require Tk" is commonly broken.  It is on RedHat 9 and 
Fedora Core 1.

[EMAIL PROTECTED] tclsh
% package require Tk
can't find package Tk


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-01-03 03:58

Message:
Logged In: YES 
user_id=21627

The patch looks fine, please apply.

As for documentation: it has been custom to just document
the changes (and perhaps write the bare minimum of structure
to add the changes) to lib/tkinter.tex. I see no problem
with some features being documented and others not - over
time, documentation will complete if we continue with this
custom.

I wonder whether the loading of Tk can be simplified as
evaluating
"package require Tk" instead of calling Tk_Init(); I don't
know what the difference between these two is.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470
_______________________________________________
Patches mailing list
[email protected]
http://mail.python.org/mailman/listinfo/patches

Reply via email to