-
-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow setting line_buffering on existing TextIOWrapper #74711
Comments
Currently, if you want to change the line buffering behaviour of standard streams, you can create a new stream and assign it to sys.{stdout,stderr,stdin}. Unfortunately, it is common for references to the old streams to be stored in various places (such as logging configuration, or third-party libraries). Replacing them all is probably a hopeless cause. It would be much better if one could simply write |
This looks similar to bpo-15216 and may be merged with it. At least setting line_buffering and encoding should have unified interface. I see two possibilities of making this Pythonic:
|
I don't think those two issues need to be merged. Setting line_buffering and write_through is almost trivial, while setting the encoding seems to take a significant amount of effort. That said, I agree that a unified interface may be nice. Perhaps a reconfigure(**kwargs) method? |
First at all, I'm not sure that allowing to modify TextIOWrapper settings after creation is a good idea. I would be feeling uncomfortable if the third-party library changed the buffering or encoding settings of passed text stream for its own needs, and this stream is sys.stdout. For example set f.line_buffering = False for performance and break your logging. Creating a new TextIOWrapper for own needs looks safer. But changing the global state is the essential part of Nick's and your issues. This could have long-term consequences, so it is worth to discuss the principle on the Python-Dev mailing list before applying the changes. |
Le 01/06/2017 à 12:41, Serhiy Storchaka a écrit :
Agreed that third-party libraries should not, but we're talking about
Now you may have two TextIOWrappers alive wrapping the same buffered IO |
Right, the request/requirement for in-place configuration changes arise from the fact the underlying buffer objects can't readily be shared, while makes swapping out the wrapper problematic if others may already have references to the original. The "Don't do this implicitly in a library" admonition is then really the same one that applies to any unusual tinkering with global state (e.g. monkeypatching): you can definitely break things if you do it carelessly, so let the main application decide if and when global state updates are appropriate. I do like "reconfigure()" as the API name, since that's then nicely amenable to expanding to all the settings supported by |
Thanks. I'll produce an updated PR using reconfigure() for line_buffering and write_through. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: