_io.TextIOWrapper._CHUNK_SIZE ignores underlying buffer size, defaults 8192

Bug report

Bug description:

If I try to read a line from a file containing a very long line using open(path, buffering=n).readline(), it reads in chunks of 8192 regardless of the value of n. I would like it to respect n so that I can reduce the number of syscalls.

I can manually work around this by setting the undocumented attribute _CHUNK_SIZE, but I think this should be done automatically. The number 8192 is hard-coded in _io_TextIOWrapper___init___impl; I propose automatically setting it to the buffer size of the underlying _io.BufferedReader / _io.BufferedWriter / _io.BufferedRandom (if the underlying object is one of those).

docker run --rm -it python:3.14.6 bash
apt-get update && apt-get install -y strace
python3 -c 'print("x"*100000)' > f
# f.readline ignores the buffer size
strace -e trace=read python3 -c 'open("f", buffering=100000).readline()' # calls `read(3, ..., 8192)`
# workaround: set f._CHUNK_SIZE
strace -e trace=read python3 -c 'f = open("f", buffering=100000); f._CHUNK_SIZE = 1000000; f.readline()' # calls `read(3, ..., 1000000)`
# aside: f.buffer.readline respects the buffer size
strace -e trace=read python3 -c 'f = open("f", buffering=100000); f.buffer.readline()' # calls `read(3, ..., 100000)`

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Comienza en Modules/_io/textio.c, en _io_TextIOWrapper___init___impl, donde el issue identifica el tamaño de bloque codificado de forma fija como 8192. Reproduce el comportamiento con los comandos open(), readline() y strace proporcionados y, después, sigue cómo se expone el tamaño del objeto almacenado en búfer subyacente. Se considera completado cuando readline() usa ese tamaño de búfer para los tipos de objetos almacenados en búfer relevantes sin requerir _CHUNK_SIZE.