Logged In: YES 
user_id=488897

> Clarifying (1a) -- Why (pre-patch) were Windows and 
> Unix intentionally set to act differently?  Is there
something 
> in the default runtimes or libraries which makes 
> (expected?) performance very different on the platforms?

The difference is not Windows versus Unix, but
Unix-with-readline versus Unix-without-readline and
Windows-without-readline. I wasn't there when PyOS_InputHook
was first added to Python, but I doubt that the difference
in behavior was intentional. Essentially, I think that the
behavior of Tkinter (on Python-without-readline) is a design
flaw.

> Clarifying (1b) -- Is ten times per second enough?  0.1 
> seconds is long enough that people can notice it.  If the 
> pre-patch version cycles 50 times/second, then going to 
> only 10 times/second might make the interface seem 
> sluggish.  I'm not sure I'm qualified to make this 
> judgement myself, but it is a concern.

Good point. The 10 times/second is the default used in
readline, and hence this is the frequency at which
PyOS_InputHook is called  in Python-with-readline. I can
modify the patch to increase this to 50 times/second.

> Clarifying (1c) -- My (possibly wrong) understanding is 
> that before this pair of patches, unix effectively did an 
> active check for input, but the windows version waited for 
> notification from the OS that keyboard input was available 
> -- and after this, both would actively check N times/
> second.  If both are just passively waiting, then I'm not 
> sure what the 20ms/100ms timeout actually does.

That is correct. Pre-patch, both Unix and Windows sit in a
loop inside Tkinter's EventHook function that calls
Tcl_DoOneEvent and check for keyboard input, and then sleep
for 20 ms. The check for keyboard input is done via a call
to _kbhit (on Windows) or select (on Unix, hiding inside
Tcl/Tk's Tcl_DoOneEvent function). Post-patch, this loop is
located inside the my_fgets function. It works essentially
the same, except that I'm using WaitForSingleObject (on
Windows) / select (on Unix) for the timeout.

> If python is running as a batch process, then forcing it 
> back into the "is there input" section several times a 
> second (even though there is never any keyboard input) 
> will cause the program to take more clocktime.

Also a good point. I will modify the patch such that it will
skip to fgets immediately if PyOS_InputHook==NULL. In a
batch process, there is no reason to load a GUI extension
module such as Tkinter, so PyOS_InputHook should be NULL.

> Clarifying (2) -- The pre-patch version can certainly take 
> events (including keyboard events) during the event loop.  
> What you can't do is:

> """
> (define/run a bunch of stuff)
> ...
> start the event loop
> ...
> (define/run a bunch more stuff)
> """

Sure you can. I do it all the time. Try this, for example:
>>> from Tkinter import *
>>> Label(text="Label1").pack()
# ... Label1 appears
>>> print "more stuff I want to do"
more stuff I want to do

Here, Label1 appears and responds to events, even though I
did not run mainloop. Note that pre-patch, this does not
work on Cygwin; post-patch, it works on Cygwin too.

> You need to set up all the definitions and event handlers 
> before the loop starts, or else do them as a result of 
> events.  Roughly, calling mainloop has to be the *last* 
> thing you do in a given thread.  Which leads to (3)

You don't need to call mainloop at all. This is quite useful
for scientific visualization:
>>> do_some_calculation()
>>> plot_the_result()
>>> if dont_like_the_plot: do_some_more_calculations()
>>> plot_the_new_result()
Here, you never need to start or stop the event loop. It
continues running as long as PyOS_InputHook is set
appropriately by the extension module that does the plotting.

> Clarifying (3)  -- Why not just assume threads?  The 
> problem you are trying to solve can't exist without threads. 
> Assuming threads won't make anything fail any harder 
> than it does now.  If you default to dummy-threads and 
> ensure that the event-loop the *last* pseudo-thread, you'll 
> even clear up some bugs in carelessly written single-
> threaded code. 

Whether or not Tkinter should have been coded with threads
is a separate question. Tkinter is written for a single
thread, using an event loop to handle window events and
keyboard input. While it is possible to rewrite Tkinter to
use threads, that would constitute a separate patch (and
would probably not have a good chance of getting accepted,
since Tkinter already works well as a single thread).