cpython/Lib/test/test_io/__init__.py
Miss Islington (bot) 2af5a3d0ea
[3.15] gh-161458: Move test_winconsoleio and test_file_eintr into test_io (GH-161460) (#161523)
gh-161458: Move test_winconsoleio and test_file_eintr into test_io (GH-161460)

* gh-161458: Move test_file_eintr into test_io
* gh-161458: Move test_winconsoleio into test_io
* gh-161458: Move test_free_threading/test_io into test_io as test_free_threading
* gh-161458: Skip test_io.test_free_threading on GIL builds

   The test_free_threading package skipped these on GIL builds.
* gh-161458: Remove the test module list from the test_io docstring

   It goes stale whenever a module is added or moved.
* gh-161458: Point to I/O tests outside test_io in its docstring
(cherry picked from commit 5106b9195f)

Co-authored-by: Cody Maloney <cmaloney@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-06 16:27:54 -08:00

26 lines
1,021 B
Python

"""Tests for the io module and its implementations (_io and _pyio)
Tests are split across multiple files to increase
parallelism and focus on specific implementation pieces.
Tests for code that uses io live with that code, for example:
* test_capi.test_file - the PyFile_* C API
* test_builtin, test_print - open(), input() and print()
* test_cmd_line, test_subprocess - stdio buffering and newlines at startup
and through pipes
* test_utf8_mode - UTF-8 mode encodings, including with _pyio
* test_os, test_eintr - fd-level I/O and EINTR retries
.. attention::
When writing tests for io, it's important to test both the C and Python
implementations. This is usually done by writing a base test that refers to
the type it is testing as an attribute. Then it provides custom subclasses to
test both implementations. This directory contains lots of examples.
"""
import os
from test.support import load_package_tests
def load_tests(*args):
return load_package_tests(os.path.dirname(__file__), *args)