[issue45804] IDLE - faster shell writing

[wyz23x2]

Change by wyz23x2 :


--
assignee:  -> terry.reedy
components: +IDLE

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45804] IDLE - faster shell writing

[Roger Serwy]

Roger Serwy  added the comment:

All good questions, Terry! I do have a git clone of the cpython repo, but I 
haven't worked through the new commit/patch process since Mercurial. I'm a bit 
rusty.

The buffering provided is for calls to `write`. It does not do any line 
buffering. Calls to `isatty` will behave the same. The negative side effect is 
that the subprocess will proceed as if writes have been committed to the 
PyShell window, so any pending transfers can be lost if the subprocess 
terminates unexpectedly.

I used a separate OS thread to handle the transfer of the writes rather than 
using the Tcl/Tk event loop. The Tcl/Tk loop runs on the main thread, so any 
long-running processes will prevent a `.after` callback function from being 
called.

The base class was not changed. I haven't followed all the changes to the 
stream class (and its implications) since 3.5, so the code subclasses the newer 
`StdOutputFile` class to minimize disruption.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45804] IDLE - faster shell writing

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Thank you Roger.  Good to hear from you.  

https://stackoverflow.com/questions/66286367/why-is-my-function-faster-than-pythons-print-function-in-idle,
 Feb 2021, was about this issue.  In my answer I verified the claim and then 
showed in further experiments that batching prints solved the issue.  #43283 
added a paragraph to the IDLE doc explaining the problem and suggesting that 
users could work around it by batching and joining before printing.  Buffering 
the streams to do so is an appealing alternative.  I intended to make sure that 
exceptions are completely and not just partly joined and sent in one write.

Some immediate questions:

Can buffering the output streams have any negative consequences.  Does it 
affect isatty, for instance, or anything checking line buffering?  

In case a user is interactively developing a tkinter GUI, IDLE already runs 
tcl.update() in a 50 ms after loop.  Could this be used to trigger writes, by 
calling flush()?

Did you consider using io.TextIOWrapper instead the current TextIOBase as base 
class for the output classes?

I am guessing that you do not have a python/cpython clone for making PRs.  
Tomorrow, I will try to find out how to make apply a .patch file to mine and do 
so.

--
versions: +Python 3.11 -Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45804] IDLE - faster shell writing

[Roger Serwy]

New submission from Roger Serwy :

The shell provided by IDLE uses synchronous sys.stdout.write() calls between 
the subprocess and the front-end, leading to very slow writes. The provided 
patch proposes buffering the stdout/stderr streams in the subprocess and then 
sending a single update after 50ms. The patch also provides back pressure on 
the buffer so that it doesn't grow without bound.

When trying the behavior of the patch, disable the squeezer extension, or set 
its limit to 1000. Then in the shell, run:

for i in range(500): print(i)

The output will instantly appear in the shell.

--
files: idlelib_buffer_output.patch
keywords: patch
messages: 406306
nosy: roger.serwy, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE - faster shell writing
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file50438/idlelib_buffer_output.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com