homepage

Logged In: YES 
user_id=488897
Your comments made me realize that since fixing
PyOS_InputHook's behavior is potentially too disruptive,
it's probably better not to do that with a simple patch. So
I think it's best to reject this patch. PyOS_InputHook and
event loops in general probably should be discussed in some
more detail on python-dev before making changes to Python.
For the record, I wrote a response to the three issues you
raised. You are right of course on #1, but I don't think #2
and #3 are valid --see below. Thanks for looking at this patch.
#1:
> if the system is not windows, it invokes select
> unconditionally; this should be conditioned with HAVE_SELECT
You are certainly right here. While this patch can probably
be fixed, this code would have to be tested on a large
number of platformsto make sure this patch won't break
python for somebody (which is why I'm shying away from doing
this in a patch right now).
#2
> the Windows version uses kbhit; this may or may not
> operate on the same handle as hStdIn. In fact, it likely is
> a different handle. See the source code of the crt: kbhit
> uses _coninpfh, which is created from opening CONIN$. Try
> using GetNumberOfConsoleInputEvents/PeekConsoleInput
> instead, checking for a KEY_EVENT event.
In the patch, I test if the file descriptor is a tty. The
_kbhit() function is called only if that is the case. So
AFAICT, using _coninpfh is the right thing to do. Note also
that the same code is already being used in _tkinter: In the
EventHook function, _kbhit is used to decide if the program
should return from the EventHook function because input is
available at stdin. So essentially, I am moving code from
_tkinter to Python's main loop, to make it available for
extension modules other than _tkinter.
I'm not sure how GetNumberOfConsoleInputEvents or
PeekConsoleInput would help us.
#3
> as stdin may be buffered, it may be the case that there is
> already input available, even though the file descriptor is
> not ready.
I don't think the situation can occur in which select blocks
although input is already available in the buffer used by fgets.
With thanks to comp.unix.programmer:
If python is reading input from a tty, the input mode is
line buffered. Each time the user hits return, a complete
line is available to fgets, so buffering is not a problem.
If, however, python is reading input from disk, the input
mode is block buffered. When the end of the file is reached,
EOF is flagged, and select will return immediately. So if
fgets reads a block of data and stores it in its buffer, and
still more data is available in the file, the file
descriptor will be ready and select returns. If, however,
fgets reads the last block of data and stores it in its
buffer, EOF is set, so select won't block in this case either.
Note that this is also code that already exists in Python's
_tkinter. If _tkinter is imported, before calling fgets,
Python sits in a loop inside the EventHook function. Except
on Windows platforms, the fileno of stdin is passed to
Tcl_CreateFileHandler, where it is used in a call to select
inside the Tcl_WaitForEvent function. The call to select
will trigger a call to MyFileProc in _tkinter.c if input is
available, causing EventHook to return so that fgets can be
called. So essentially, the same code exists already inside
_tkinter (with the call to select buried inside Tcl).