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
Remove module level functions in _tkinter that depend on TkappObject #47888
Comments
mainloop() is a method of a Tkapp object, but it's also a method of It always crashs in my Python 3.0, but not in Python 2.6. Solution: just remove _tkinter.mainloop() => it should have no side |
Looks fine to me. |
gpolo agree to remove it. If no one is opposed for this change, can |
"tkinter.mainloop" seems used in a bunch of places according to Google http://www.google.com/codesearch?hl=fr&lr=&q=%22tkinter.mainloop%22&sbtn=Rechercher |
On Wed, Dec 31, 2008 at 2:24 PM, Antoine Pitrou <report@bugs.python.org> wrote:
Yes, those are not _tkinter.mainlooop, they are Tkinter.mainloop.
|
On Wed, Dec 31, 2008 at 2:27 PM, Guilherme Polo <report@bugs.python.org> wrote:
Or were you referring to my other comment about removing it from |
Well, well, sorry for the noise! |
The patch is incorrect. Tkapp_Mainloop is supposed to work both as a The same issue probably also affects other functions that double both as |
Ok. In Python 2.x, selfptr is NULL whereas selfptr is a pointer to the
Which code? I don't see which code uses _tkinter.mainloop. I saw code |
The patch looks right in principle. Please make sure not to include Please also consider all similar cases, such as Tkapp_CreateFileHandler.
The code inside the function: all tests whether self is NULL. If |
Victor, you seem to be confusing "code that supports it" with "functions Now, I'm much more in favour to remove it from moduleMethods than from
Although the reason #2 won't just work after removing mainloop from the |
Would you apply the same reasoning to the other Tkapp methods available IIRC, these functions were there first; the Tkapp object was added I'm not opposed to removing these module functions now (not even for
To me, it makes perfect sense. Windowing events are a global, and not
This entire machinery got added when Tcl started supporting threads in In the old days, Python's threading could be used with Tcl just fine; So, no: the "dispatching" member is there for continued support of
That is a good reason. We would still need a complete patch. |
Oh ok, I didn't understood what "code that supports it" mean.
Yes, right. I also prefer smaller code base with same functions ;-) |
As I see all those functions that are calling into Tcl should be moved
That is way to see it. But what I was taking into account was
That is exactly one of the reasons to move mainloop and others from
But I don't see a RPC being used there, I just see some polling.
|
Consider Tkapp_Call (e.g.). If this is invoked in the Tk interpreter If the call is made from a different thread, then a Tkapp_CallEvent In the interpreter thread, Tkapp_CallProc is invoked, which extracts |
This is all true but the dispatching isn't used there actually. |
Right. If the main thread doesn't actually invoke mainloop(), the |
Here is a patch, two actually. The next one deprecates the functions in |
These look fine. I think further changes are necessary: One minor nit: I personally dislike function pointer casts, because they |
Indeed, I forgot to look into the Python code. I also see as redundant the checks for _tkinter._flatten and
Ah, it is nice you ask this. I was indeed going to move then, but I I get an empty string with the text below, but I was expecting some import _tkinter
def mybgerror(errmsg):
print errmsg
called = []
def bad():
called.append(True)
raise InvalidThing
x = _tkinter.create()
x.createcommand("bad", bad)
x.createcommand("bgerror", mybgerror)
x.call("after", 1, "bad")
while not called:
_tkinter.dooneevent()
_tkinter.dooneevent() I ended up finding another problem (or problems, I forgot to annotate import _tkinter
def bad():
raise InvalidThing
x = _tkinter.create()
x.createcommand("bad", bad)
x.call("bad") Results in: Traceback (most recent call last):
File "my_badtests/test1.py", line 7, in <module>
x.call("bad")
_tkinter.TclError Meaning call is overwriting a python error by a tcl error, but since But these all would deserve another(s) issues, so I will be moving
Fine. |
s/text/test |
I haven't tried reproducing these problems, but this all sounds plausible. So go ahead and check in all the changes for this issue. Don't forget Misc/NEWS entries, and don't forget to svnmerge block If you rather prefer me to check it in, please let me know. |
Thanks Martin, trunk: r68231 (blocked on py3k) |
Uh, I forgot about the code removal in __init__ in the first commits. r68242, r68244 now |
gpolo: Nice patches, good job and thanks ;-) |
See bpo-22155 for fixing the createfilehandler FAQ documentation |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: