Terry J. Reedy <tjre...@udel.edu> added the comment:
Summary: With IDLE running normally, with 2 processes, "input('prompt')" in the
main thread blocks execution of "print('whatever')" in a separate thread.
(Verified on Windows with 3.9 and macOS with 3.8.) The user can respond to the
prompt without being disrupted by continued output.
For standard single process python or IDLE (started with -n), the thread output
continues and can be mixed in with both the input prompt and user response and
in the example, scroll prompt and even initial response off the screen.
I presume the difference is related to IDLE routing user-code use of the std
streams through a 3rd thread that manages the inter-process socket connection.
But I did not see why after more than an hour of looking.
Overall, I think the experience with input() in IDLE is more useful and less
confusing, especially to beginners. (I am having trouble imagining when the
intermixing and interference would be useful.)
Guido, do you have any recollection of whether the IDLE difference, when using
an execution process, is intended? Do you regard intermixing input prompts and
responses and thread output as a required feature of Python, or as an
(unfortunate, IMHO) side-effect of using a dumb text interface?
Note: in IDLE, '>>>' come from IDLE, not the usercode execution process. Hence
a) asynchonous outputs from the execution process can appear on the screen, and
b) IDLE, unlike the standard REPL, can and does prevents such text from mixing
into and spoiling user code input. (It may appear after '>>>' but is put
before the input area. This is an intentional interface difference.
My *immediate* inclination is to regard the IDLE difference as overall being a
positive feature and leave it alone. But it should be documented in "Running
user code", which is already mostly about stdio differences.
I don't deny that blocking output while a user responds is a negative. I just
see mixing streams as worse. To work towards not blocking while not mixing, I
replaced the thread loop with
for i in range(10): sys.stdout.write(f'some text {i}\n')
and separated input(prompt) into sys.stdout.write(prompt) and
sys.stdin.readline().
Observations:
1. .write is better as it is atomic, while print() prints '\n' separately, with
sometimes undesirable results.
2. The block is from readline.
3. While output to Shell is blocked on readline, typing a continuation-invoking
'.' or calltip-invoking '(' in either Shell or editor allows one line of
output. Both send a non-stdio message from Shell to the run process and back.
This might be a clue as to how read/readline blocks.
In the longer term, after some changes to Shell, I could imagine replacing
__builtins__.input with a function that would check if sys.stdin/out were
IDLE's replacements and if so, send the prompt to Shell tagged as 'prompt'
rather than as 'stdout', so that Shell could keep prompt and user response
separate from regular output, similar to the way now done for code input. If
.readline cannot be made to not block output, it might work for Shell to send
the response back tagged as 'response' rather than as 'stdin' and not use
readline.
----------
nosy: +gvanrossum, taleinat
stage: -> needs patch
versions: +Python 3.8, Python 3.9
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
