[issue41147] Document that redirect_std{out, err} yield the new stream as the context variable
Change by Peter Law : -- keywords: +patch pull_requests: +20352 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21199 ___ Python tracker <https://bugs.python.org/issue41147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41147] Document that redirect_std{out, err} yield the new stream as the context variable
New submission from Peter Law :
In `contextlib`, `_RedirectStream` (the class behind `redirect_stdout` and
`redirect_stderr`) returns the current stream target as its context variable,
which allows code like this:
``` python
with redirect_stdout(io.StringIO()) as buffer:
do_stuff()
use(buffer.getvalue())
```
where you capture the redirected stream without a separate line to declare the
variable.
This isn't documented (See
https://docs.python.org/3/library/contextlib.html#contextlib.redirect_stdout),
yet is potentially useful.
Unless there's a reason that this isn't documented, I propose that the
documentation be modified to include it.
Aside: After initially reporting this against the typeshed
(https://github.com/python/typeshed/issues/4283) I'm also working on a PR to
the typeshed to include this there.
--
assignee: docs@python
components: Documentation
messages: 372513
nosy: PeterJCLaw, docs@python
priority: normal
severity: normal
status: open
title: Document that redirect_std{out,err} yield the new stream as the context
variable
type: behavior
___
Python tracker
<https://bugs.python.org/issue41147>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40540] inconstent stdin buffering/seeking behaviour
New submission from Peter Law : `sys.stdin` (on Windows, tested Pythons 3.6-3.8) appears to have different seeking behaviour depending on the source of the incoming data. This seems arguably reasonable given that `stdin` isn't always seekable, however even in the failing case `sys.stdin.seekable()` returns `True`. Given the `reader.py` source: ``` python import sys def coding_check(lines, default='utf-8'): for line_number, line in enumerate(lines, 1): print((line_number, line)) if line_number > 2: break return default stdin = sys.stdin print(stdin.seekable()) stdin.seek(0) coding_check(stdin) stdin.seek(0) print(stdin.read()) ``` then for two similar invocations we get differing results: ``` > python reader.py < reader.py True (1, 'import sys\n') (2, '\n') (3, '\n') import sys def coding_check(lines, default='utf-8'): <... etc. redacted for brevity> > ``` ``` > type reader.py | python reader.py True (1, 'import sys\n') (2, '\n') (3, '\n') > ``` I realise that raw standard input isn't always seekable, however I would hope that in the case that it isn't seekable that `.seekable()` would tell us that. I also tried wrapping `stdin.buffer` in an `io.BufferedReader` and using that, however for short files (three lines or less) this issue is still present. I'm not sure if this is something I'm misunderstanding around buffered readers, a variation on this issue or another issue though. -- components: Windows messages: 368306 nosy: PeterJCLaw, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: inconstent stdin buffering/seeking behaviour type: behavior ___ Python tracker <https://bugs.python.org/issue40540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0, DstOffset=1
Peter Law added the comment: Awesome, thanks for fixing this. -- nosy: +PeterJCLaw ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23600> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
