In some rare situations, you might care what stdin is connected to. Mostly, you don't care -- you just read stdin.
In someprocess | python myprogram.py, stdin is connected to a pipe; in this case, the stdout of the previous process. You simply read from sys.stdin and you're reading from the other process. [Note that in Windows, however, there's still (potentially) a "CON" device with a keyboard. It just won't be sys.stdin.]
In python myprogram.py <someFile, stdin is connected to a file. You simply read from sys.stdin and you're reading from the file.
In python myprogram.py, stdin is left connected to the console (/dev/ttyxx in *nix). You simple read from sys.stdin and you're reading from the keyboard.
Note the common theme in the above three cases. You simply read from sys.stdin and your program's environment defines everything for you. You don't check "to see if data is available on stdin for reading". It's already available.
Sometimes, you want a keyboard interrupt (or other shenanigans). Python, BTW, has a keyboard interrupt as a first-class feature of the I/O elements. Control-C raises an interrupt during I/O (it won't break into a tight loop, but it will signal a program that prints periodically.)
Sometimes you need to find out what kind of file stdin is connected to.
Something like os.isatty( sys.stdin.fileno() ) If sys.stdin is a TTY, you're program was left connected to the windows "CON" (the keyboard). If sys.stdin is not a TTY, it's connected to a file or a pipe.
Example
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\slott>python
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import sys
>>> os.isatty( sys.stdin.fileno() )
True
>>>
The value of True tells me Python is running without a file or pipe attached. sys.stdin is the keyboard. Using windows kbhit is needless.
A value of False tells me Python is running with a file or pipe attached. sys.stdin is NOT the keyboard. Checking kbhit might be meaningful. Also, I could open the CON: device and read the keyboard directly, separate from sys.stdin.
I'm not sure why you need "to see if data is available on stdin for reading". It might help to update your question with additional details of what you're trying to accomplish.