«

I want to do a very simple thing in Windows. (Using Python Shell.)

I want to write a prompt to sys.stdout and read the user input.
(Ideally, without waiting for a newline.)

Here are the problems I'm encountering. Newbie problems, no doubt.

sys.stdin.read() gives me an attribute error
sys.stdin.readline() doesn't block waiting for input. And even
if it did, it would block waiting for a newline.

I thought sys.stdin was supposed to behave like a File object.
In Python Shell it's actually idlelib.rpc.RPCProxy, but that's
understandable. But shouldn't it support read()?

And without termios (unavailable on Windows), how would I
set the file to nonblocking read mode? PyWin32 doesn't seem to
have any help, but I might just have missed it.

I assume a programming language & system would have a pretty
simple way to get input from the user!

Thanks,
Jeff

PS: Python rocks. I've used it a lot, but so far only on UNIX,
and generally for filters or web scripts -- haven't needed to
ask any questions before.

On Sat, 04 Sep 2004 11:23:12 -0400, Jeff Learman <>
declaimed the following in comp.lang.python:

>
> I want to do a very simple thing in Windows. (Using Python Shell.)
>
> I want to write a prompt to sys.stdout and read the user input.
> (Ideally, without waiting for a newline.)
>
Library reference
Section 22 (M$ specific)
Subsection .1.2 (Console I/O)

lib> kbhit( )
lib> Return true if a keypress is waiting to be read.
lib>
lib> getch( )
lib> Read a keypress and return the resulting character. Nothing is
echoed to the console. This call will block if a keypress is not already
available, but will not wait for Enter to be pressed. If the pressed key
was a special function key, this will return '\000' or '\xe0'; the next
call will return the keycode. The Control-C keypress cannot be read with
this function.
lib>
lib> getche( )
lib> Similar to getch(), but the keypress will be echoed if it
represents a printable character.
lib>
lib> putch( char)
lib> Print the character char to the console without buffering.
lib>
lib> ungetch( char)
lib> Cause the character char to be ``pushed back'' into the console
buffer; it will be the next character read by getch() or getche().

stdin tends to be buffered by the OS -- the OS doesn't release
anything until the new-line. You have to use OS specific operations to
get to the data in the buffer.

--
> ================================================== ============ <
> | Wulfraed Dennis Lee Bieber KD6MOG <
> | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

(sheepish grin: didn't see the MS-specific chapter!)

Thanks

Dennis Lee Bieber wrote:

> On Sat, 04 Sep 2004 11:23:12 -0400, Jeff Learman <>
> declaimed the following in comp.lang.python:
>
>
>>I want to do a very simple thing in Windows. (Using Python Shell.)
>>
>>I want to write a prompt to sys.stdout and read the user input.
>>(Ideally, without waiting for a newline.)
>>
>
> Library reference
> Section 22 (M$ specific)
> Subsection .1.2 (Console I/O)
>
> lib> kbhit( )
> lib> Return true if a keypress is waiting to be read.
> lib>
> lib> getch( )
> lib> Read a keypress and return the resulting character. Nothing is
> echoed to the console. This call will block if a keypress is not already
> available, but will not wait for Enter to be pressed. If the pressed key
> was a special function key, this will return '\000' or '\xe0'; the next
> call will return the keycode. The Control-C keypress cannot be read with
> this function.
> lib>
> lib> getche( )
> lib> Similar to getch(), but the keypress will be echoed if it
> represents a printable character.
> lib>
> lib> putch( char)
> lib> Print the character char to the console without buffering.
> lib>
> lib> ungetch( char)
> lib> Cause the character char to be ``pushed back'' into the console
> buffer; it will be the next character read by getch() or getche().
>
> stdin tends to be buffered by the OS -- the OS doesn't release
> anything until the new-line. You have to use OS specific operations to
> get to the data in the buffer.
>

Hmm, getch() and getche() don't block.

The lib ref page says, "Read a keypress and return the resulting
character. Nothing is echoed to the console. This call will block if a
keypress is not already available, but will not wait for Enter to be
pressed." However:

import msvcrt

print msvcrt.kbhit()
print "prompt: ",
ch = msvcrt.getche()
print
print ord(ch)

Results -- without typing a key:

0
prompt:
255

Any ideas?

Thanks,
Jeff

Dennis Lee Bieber wrote:

> On Sat, 04 Sep 2004 11:23:12 -0400, Jeff Learman <>
> declaimed the following in comp.lang.python:
>
>
>>I want to do a very simple thing in Windows. (Using Python Shell.)
>>
>>I want to write a prompt to sys.stdout and read the user input.
>>(Ideally, without waiting for a newline.)
>>
>
> Library reference
> Section 22 (M$ specific)
> Subsection .1.2 (Console I/O)
>
> lib> kbhit( )
> lib> Return true if a keypress is waiting to be read.
> lib>
> lib> getch( )
> lib> Read a keypress and return the resulting character. Nothing is
> echoed to the console. This call will block if a keypress is not already
> available, but will not wait for Enter to be pressed. If the pressed key
> was a special function key, this will return '\000' or '\xe0'; the next
> call will return the keycode. The Control-C keypress cannot be read with
> this function.
> lib>
> lib> getche( )
> lib> Similar to getch(), but the keypress will be echoed if it
> represents a printable character.
> lib>
> lib> putch( char)
> lib> Print the character char to the console without buffering.
> lib>
> lib> ungetch( char)
> lib> Cause the character char to be ``pushed back'' into the console
> buffer; it will be the next character read by getch() or getche().
>
> stdin tends to be buffered by the OS -- the OS doesn't release
> anything until the new-line. You have to use OS specific operations to
> get to the data in the buffer.
>

On Sat, 04 Sep 2004 16:35:00 -0400, Jeff Learman <>
declaimed the following in comp.lang.python:


> Any ideas?
>
Seems to work here (W98SE, "MS-DOS PROMPT" window)...

G:\>type t.py
import msvcrt

print msvcrt.kbhit()
print "prompt: ",
ch = msvcrt.getche()
print
print ord(ch)

G:\>python t.py
0
prompt: a
97

G:\>python t.py
0
prompt:
0


Note -- the second one was <ctrl-@>; IOW, a "null" byte.

G:\>type t.py
import msvcrt

print msvcrt.kbhit()
print "prompt: ",
ch = msvcrt.getche()
print
print `ch`


G:\>python t.py
0
prompt:
'\x00'

--
> ================================================== ============ <
> | Wulfraed Dennis Lee Bieber KD6MOG <
> | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

Aha. It works for me too, if I run from DOS prompt.
It's only failing when I run from IDLE Python Development Environment.
I'll file a bug report.

Thanks for your help! I'd be happy to help you out in return;
just let me know if you want some piano or Hammond organ tracks
for original recordings

Jeff

Dennis Lee Bieber wrote:

> On Sat, 04 Sep 2004 16:35:00 -0400, Jeff Learman <>
> declaimed the following in comp.lang.python:
>
>
>
>>Any ideas?
>>
>
> Seems to work here (W98SE, "MS-DOS PROMPT" window)...
>
> G:\>type t.py
> import msvcrt
>
> print msvcrt.kbhit()
> print "prompt: ",
> ch = msvcrt.getche()
> print
> print ord(ch)
>
> G:\>python t.py
> 0
> prompt: a
> 97
>
> G:\>python t.py
> 0
> prompt:
> 0
>
>
> Note -- the second one was <ctrl-@>; IOW, a "null" byte.
>
> G:\>type t.py
> import msvcrt
>
> print msvcrt.kbhit()
> print "prompt: ",
> ch = msvcrt.getche()
> print
> print `ch`
>
>
> G:\>python t.py
> 0
> prompt:
> '\x00'
>