[New-bugs-announce] [issue40540] inconstent stdin buffering/seeking behaviour

[Peter Law]

New submission from Peter Law <PeterJCLaw+py at 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 <report at bugs.python.org>
<https://bugs.python.org/issue40540>
_______________________________________