[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-03 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-03 Thread Antoine Pitrou
Antoine Pitrou added the comment: New changeset 3c2817b6884a5fcf792197203f3c26b157210607 by Antoine Pitrou in branch 'master': Fix bpo-30526: Add TextIOWrapper.reconfigure() and a TextIOWrapper.write_through attribute (#1922)

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-02 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- pull_requests: +2002 ___ Python tracker ___ ___

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-02 Thread Antoine Pitrou
Antoine Pitrou added the comment: Thanks. I'll produce an updated PR using reconfigure() for line_buffering and write_through. -- ___ Python tracker ___

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-02 Thread Nick Coghlan
Nick Coghlan added the comment: 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

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-01 Thread Antoine Pitrou
Antoine Pitrou added the comment: Le 01/06/2017 à 12:41, Serhiy Storchaka a écrit : > > 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

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-01 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: 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

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-01 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- stage: -> patch review ___ Python tracker ___ ___

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-01 Thread Antoine Pitrou
Antoine Pitrou added the comment: 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

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-06-01 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: This looks similar to issue15216 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: * Make attributes writeable. * Add a method (configure(), reopen(), or

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-05-31 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- pull_requests: +1965 ___ Python tracker ___ ___

[issue30526] Allow setting line_buffering on existing TextIOWrapper

2017-05-31 Thread Antoine Pitrou
New submission from Antoine Pitrou: 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