New submission from Peter Law <peterjclaw...@gmail.com>:
`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 <rep...@bugs.python.org>
<https://bugs.python.org/issue40540>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
