Can not reproduce it on main and 3.13 branch. Would you mind providing more detail?

@Zheaoli
Did you run on FreeBSD ?
What other details can I provide?

Did you run on FreeBSD ?

Yes,

root@freebase-test:~ # fastfetch
```                        `        root@freebase-test
  ` `.....---.......--.```   -/     ------------------
  +o   .--`         /y:`      +.    Host: Standard PC (i440FX + PIIX, 1996) (pc-i440fx-9.0)
   yo`:.            :o      `+-     Kernel: FreeBSD 14.1-RELEASE
    y/               -/`   -o/      Uptime: 19 mins
   .-                  ::/sy+:.     Shell: sh
   /                     `--  /     Terminal: /dev/pts/0
  `:                          :`    CPU: QEMU Virtual version 2.5+ (8) @ 2.50 GHz
  `:                          :`    GPU: Unknown Device 1111 (VGA compatible)
   /                          /     Memory: 4.14 GiB / 47.96 GiB (9%)
   .-                        -.     Swap: 0 B / 1.00 GiB (0%)
    --                      -.      Disk (/): 4.31 GiB / 101.24 GiB (4%) - zfs
     `:`                  `:`       Local IP (eth0): 192.168.12.41/16
       .--             `--.         Locale: en_US.UTF-8
          .---.....----.

I encountered this problem with the python311 package, and you said that you tried 3.13

Can you try with python311?
Maybe it is already fixed in 3.13

3.11 is no longer receiving bug fixes. Can you try 3.12 or 3.13? See https://devguide.python.org/versions/

Running this on Linux on current HEAD (v3.1-alpha) I get this:

...
< ready=([], [], [])
>
< ready=([], [], [])Traceback (most recent call last):
  File "/home/duaneg/src/cpython/a.py", line 11, in <module>
    print(f'< ready={ready}')
    ~~~~~^^^^^^^^^^^^^^^^^^^^
BlockingIOError: [Errno 11] write could not complete without blocking

Which I think is actually to be expected: note this is failing in the print function, not select. It is stdout that is reporting this error. Changing stdin to be non-blocking also changes stdout likewise, since those file descriptors are reading and writing from/to the same pipe when run from a POSIX shell. Changing the print string to a much longer string (e.g. ~32k characters) makes it fail quickly and reliably.

It looks like the OP's original bug is the same, note the file reported in the error is stdout:

Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>.

In the bug report the exception is being swallowed and reported by sys.unraisablehook: this sometimes happens on HEAD too, again, I think this is to be expected when flushing stdout on shutdown fails due to it being non-blocking.

In other words, I think everything is working correctly now, and actually probably was before also, given POSIX standard in/out file descriptor semantics. It is losing error output, but that possibility is unavoidable given a non-blocking stdout.