Navigation

The io module provides Python’s main facilities for dealing with various
types of I/O. There are three main types of I/O: text I/O, binary I/O
and raw I/O. These are generic categories, and various backing stores can
be used for each of them. A concrete object belonging to any of these
categories is called a file object. Other common terms are stream
and file-like object.

Independently of its category, each concrete stream object will also have
various capabilities: it can be read-only, write-only, or read-write. It can
also allow arbitrary random access (seeking forwards or backwards to any
location), or only sequential access (for example in the case of a socket or
pipe).

All streams are careful about the type of data you give to them. For example
giving a str object to the write() method of a binary stream
will raise a TypeError. So will giving a bytes object to the
write() method of a text stream.

Text I/O expects and produces str objects. This means that whenever
the backing store is natively made of bytes (such as in the case of a file),
encoding and decoding of data is made transparently as well as optional
translation of platform-specific newline characters.

The easiest way to create a text stream is with open(), optionally
specifying an encoding:

Binary I/O (also called buffered I/O) expects and produces bytes
objects. No encoding, decoding, or newline translation is performed. This
category of streams can be used for all kinds of non-text data, and also when
manual control over the handling of text data is desired.

The easiest way to create a binary stream is with open() with 'b' in
the mode string:

Raw I/O (also called unbuffered I/O) is generally used as a low-level
building-block for binary and text streams; it is rarely useful to directly
manipulate a raw stream from user code. Nevertheless, you can create a raw
stream by opening a file in binary mode with buffering disabled:

It is also possible to use a str or bytes-like object as a
file for both reading and writing. For strings StringIO can be used
like a file opened in text mode. BytesIO can be used like a file
opened in binary mode. Both provide full read-write capabilities with random
access.

The implementation of I/O streams is organized as a hierarchy of classes. First
abstract base classes (ABCs), which are used to
specify the various categories of streams, then concrete classes providing the
standard stream implementations.

Note

The abstract base classes also provide default implementations of some
methods in order to help implementation of concrete stream classes. For
example, BufferedIOBase provides unoptimized implementations of
readinto() and readline().

At the top of the I/O hierarchy is the abstract base class IOBase. It
defines the basic interface to a stream. Note, however, that there is no
separation between reading and writing to streams; implementations are allowed
to raise UnsupportedOperation if they do not support a given operation.

The RawIOBase ABC extends IOBase. It deals with the reading
and writing of bytes to a stream. FileIO subclasses RawIOBase
to provide an interface to files in the machine’s file system.

The TextIOBase ABC, another subclass of IOBase, deals with
streams whose bytes represent text, and handles encoding and decoding to and
from strings. TextIOWrapper, which extends it, is a buffered text
interface to a buffered raw stream (BufferedIOBase). Finally,
StringIO is an in-memory stream for text.

Argument names are not part of the specification, and only the arguments of
open() are intended to be used as keyword arguments.

The abstract base class for all I/O classes, acting on streams of bytes.
There is no public constructor.

This class provides empty abstract implementations for many methods
that derived classes can override selectively; the default
implementations represent a file that cannot be read, written or
seeked.

Even though IOBase does not declare read(), readinto(),
or write() because their signatures will vary, implementations and
clients should consider those methods part of the interface. Also,
implementations may raise a IOError when operations they do not
support are called.

The basic type used for binary data read from or written to a file is
bytes. bytearrays are accepted too, and in some cases
(such as readinto) required. Text I/O classes work with
str data.

Note that calling any method (even inquiries) on a closed stream is
undefined. Implementations may raise IOError in this case.

IOBase (and its subclasses) supports the iterator protocol, meaning that an
IOBase object can be iterated over yielding the lines in a stream.
Lines are defined slightly differently depending on whether the stream is
a binary stream (yielding bytes), or a text stream (yielding character
strings). See readline() below.

IOBase is also a context manager and therefore supports the
with statement. In this example, file is closed after the
with statement’s suite is finished—even if an exception occurs:

Read and return a list of lines from the stream. hint can be specified
to control the number of lines read: no more lines will be read if the
total size (in bytes/characters) of all lines so far exceeds hint.

Resize the stream to the given size in bytes (or the current position
if size is not specified). The current stream position isn’t changed.
This resizing can extend or reduce the current file size. In case of
extension, the contents of the new file area depend on the platform
(on most systems, additional bytes are zero-filled, on Windows they’re
undetermined). The new file size is returned.

Base class for raw binary I/O. It inherits IOBase. There is no
public constructor.

Raw binary I/O typically provides low-level access to an underlying OS
device or API, and does not try to encapsulate it in high-level primitives
(this is left to Buffered I/O and Text I/O, described later in this page).

In addition to the attributes and methods from IOBase,
RawIOBase provides the following methods:

Read up to n bytes from the object and return them. As a convenience,
if n is unspecified or -1, readall() is called. Otherwise,
only one system call is ever made. Fewer than n bytes may be
returned if the operating system call returns fewer than n bytes.

If 0 bytes are returned, and n was not 0, this indicates end of file.
If the object is in non-blocking mode and no bytes are available,
None is returned.

Write the given bytes or bytearray object, b, to the underlying raw
stream and return the number of bytes written. This can be less than
len(b), depending on specifics of the underlying raw stream, and
especially if it is in non-blocking mode. None is returned if the
raw stream is set not to block and no single byte could be readily
written to it.

Base class for binary streams that support some kind of buffering.
It inherits IOBase. There is no public constructor.

The main difference with RawIOBase is that methods read(),
readinto() and write() will try (respectively) to read as much
input as requested or to consume all given output, at the expense of
making perhaps more than one system call.

In addition, those methods can raise BlockingIOError if the
underlying raw stream is in non-blocking mode and cannot take or give
enough data; unlike their RawIOBase counterparts, they will
never return None.

Besides, the read() method does not have a default
implementation that defers to readinto().

Read and return up to n bytes. If the argument is omitted, None, or
negative, data is read and returned until EOF is reached. An empty bytes
object is returned if the stream is already at EOF.

If the argument is positive, and the underlying raw stream is not
interactive, multiple raw reads may be issued to satisfy the byte count
(unless EOF is reached first). But for interactive raw streams, at most
one raw read will be issued, and a short result does not imply that EOF is
imminent.

A BlockingIOError is raised if the underlying raw stream is in
non blocking-mode, and has no data available at the moment.

Write the given bytes or bytearray object, b and return the number
of bytes written (never less than len(b), since if the write fails
an IOError will be raised). Depending on the actual
implementation, these bytes may be readily written to the underlying
stream, or held in a buffer for performance and latency reasons.

When in non-blocking mode, a BlockingIOError is raised if the
data needed to be written to the raw stream but it couldn’t accept
all the data without blocking.

a character string or bytes object representing the path to the file
which will be opened;

an integer representing the number of an existing OS-level file descriptor
to which the resulting FileIO object will give access.

The mode can be 'r', 'w' or 'a' for reading (default), writing,
or appending. The file will be created if it doesn’t exist when opened for
writing or appending; it will be truncated when opened for writing. Add a
'+' to the mode to allow simultaneous reading and writing.

The read() (when called with a positive argument), readinto()
and write() methods on this class will only make one system call.

In addition to the attributes and methods from IOBase and
RawIOBase, FileIO provides the following data
attributes and methods:

A buffer providing higher-level access to a readable, sequential
RawIOBase object. It inherits BufferedIOBase.
When reading data from this object, a larger amount of data may be
requested from the underlying raw stream, and kept in an internal buffer.
The buffered data can then be returned directly on subsequent reads.

A buffer providing higher-level access to a writeable, sequential
RawIOBase object. It inherits BufferedIOBase.
When writing to this object, data is normally held into an internal
buffer. The buffer will be written out to the underlying RawIOBase
object under various conditions, including:

Base class for text streams. This class provides a character and line based
interface to stream I/O. There is no readinto() method because
Python’s character strings are immutable. It inherits IOBase.
There is no public constructor.

TextIOBase provides or overrides these data attributes and
methods in addition to those from IOBase:

errors is an optional string that specifies how encoding and decoding
errors are to be handled. Pass 'strict' to raise a ValueError
exception if there is an encoding error (the default of None has the same
effect), or pass 'ignore' to ignore errors. (Note that ignoring encoding
errors can lead to data loss.) 'replace' causes a replacement marker
(such as '?') to be inserted where there is malformed data. When
writing, 'xmlcharrefreplace' (replace with the appropriate XML character
reference) or 'backslashreplace' (replace with backslashed escape
sequences) can be used. Any other error handling name that has been
registered with codecs.register_error() is also valid.

newline controls how line endings are handled. It can be None,
'', '\n', '\r', and '\r\n'. It works as follows:

When reading input from the stream, if newline is None,
universal newlines mode is enabled. Lines in the input can end in
'\n', '\r', or '\r\n', and these are translated into '\n'
before being returned to the caller. If it is '', universal newlines
mode is enabled, but line endings are returned to the caller untranslated.
If it has any of the other legal values, input lines are only terminated
by the given string, and the line ending is returned to the caller
untranslated.

When writing output to the stream, if newline is None, any '\n'
characters written are translated to the system default line separator,
os.linesep. If newline is '' or '\n', no translation
takes place. If newline is any of the other legal values, any '\n'
characters written are translated to the given string.

If line_buffering is True, flush() is implied when a call to
write contains a newline character.

By reading and writing only large chunks of data even when the user asks for a
single byte, buffered I/O hides any inefficiency in calling and executing the
operating system’s unbuffered I/O routines. The gain depends on the OS and the
kind of I/O which is performed. For example, on some modern OSes such as Linux,
unbuffered disk I/O can be as fast as buffered I/O. The bottom line, however,
is that buffered I/O offers predictable performance regardless of the platform
and the backing device. Therefore, it is most always preferable to use buffered
I/O rather than unbuffered I/O for binary datal

Text I/O over a binary storage (such as a file) is significantly slower than
binary I/O over the same storage, because it requires conversions between
unicode and binary data using a character codec. This can become noticeable
handling huge amounts of text data like large log files. Also,
TextIOWrapper.tell() and TextIOWrapper.seek() are both quite slow
due to the reconstruction algorithm used.

StringIO, however, is a native in-memory unicode container and will
exhibit similar speed to BytesIO.

Binary buffered objects (instances of BufferedReader,
BufferedWriter, BufferedRandom and BufferedRWPair)
are not reentrant. While reentrant calls will not happen in normal situations,
they can arise from doing I/O in a signal handler. If a thread tries to
renter a buffered object which it is already accessing, a RuntimeError is
raised. Note this doesn’t prohibit a different thread from entering the
buffered object.

The above implicitly extends to text files, since the open() function
will wrap a buffered object inside a TextIOWrapper. This includes
standard streams and therefore affects the built-in function print() as
well.