Issue #17193: Use binary prefixes (KiB, MiB, GiB) for memory units.
This commit is contained in:
commit
0cad7eca45
|
@ -456,11 +456,11 @@ with ``bytes.decode(encoding)``. However, the manual approach is not recommende
|
|||
|
||||
One problem is the multi-byte nature of encodings; one Unicode character can be
|
||||
represented by several bytes. If you want to read the file in arbitrary-sized
|
||||
chunks (say, 1k or 4k), you need to write error-handling code to catch the case
|
||||
chunks (say, 1024 or 4096 bytes), you need to write error-handling code to catch the case
|
||||
where only part of the bytes encoding a single Unicode character are read at the
|
||||
end of a chunk. One solution would be to read the entire file into memory and
|
||||
then perform the decoding, but that prevents you from working with files that
|
||||
are extremely large; if you need to read a 2GB file, you need 2GB of RAM.
|
||||
are extremely large; if you need to read a 2 GiB file, you need 2 GiB of RAM.
|
||||
(More, really, since for at least a moment you'd need to have both the encoded
|
||||
string and its Unicode version in memory.)
|
||||
|
||||
|
|
|
@ -93,15 +93,15 @@ It defines the following constants and functions:
|
|||
Return the thread stack size used when creating new threads. The optional
|
||||
*size* argument specifies the stack size to be used for subsequently created
|
||||
threads, and must be 0 (use platform or configured default) or a positive
|
||||
integer value of at least 32,768 (32kB). If changing the thread stack size is
|
||||
integer value of at least 32,768 (32 KiB). If changing the thread stack size is
|
||||
unsupported, a :exc:`RuntimeError` is raised. If the specified stack size is
|
||||
invalid, a :exc:`ValueError` is raised and the stack size is unmodified. 32kB
|
||||
invalid, a :exc:`ValueError` is raised and the stack size is unmodified. 32 KiB
|
||||
is currently the minimum supported stack size value to guarantee sufficient
|
||||
stack space for the interpreter itself. Note that some platforms may have
|
||||
particular restrictions on values for the stack size, such as requiring a
|
||||
minimum stack size > 32kB or requiring allocation in multiples of the system
|
||||
minimum stack size > 32 KiB or requiring allocation in multiples of the system
|
||||
memory page size - platform documentation should be referred to for more
|
||||
information (4kB pages are common; using multiples of 4096 for the stack size is
|
||||
information (4 KiB pages are common; using multiples of 4096 for the stack size is
|
||||
the suggested approach in the absence of more specific information).
|
||||
Availability: Windows, systems with POSIX threads.
|
||||
|
||||
|
|
|
@ -158,7 +158,7 @@ Compressing and decompressing data in memory
|
|||
In addition to being more CPU-intensive, compression with higher presets
|
||||
also requires much more memory (and produces output that needs more memory
|
||||
to decompress). With preset ``9`` for example, the overhead for an
|
||||
:class:`LZMACompressor` object can be as high as 800MiB. For this reason,
|
||||
:class:`LZMACompressor` object can be as high as 800 MiB. For this reason,
|
||||
it is generally best to stick with the default preset.
|
||||
|
||||
The *filters* argument (if provided) should be a filter chain specifier.
|
||||
|
@ -302,8 +302,8 @@ entries in the dictionary representing the filter):
|
|||
|
||||
* ``preset``: A compression preset to use as a source of default values for
|
||||
options that are not specified explicitly.
|
||||
* ``dict_size``: Dictionary size in bytes. This should be between 4KiB and
|
||||
1.5GiB (inclusive).
|
||||
* ``dict_size``: Dictionary size in bytes. This should be between 4 KiB and
|
||||
1.5 GiB (inclusive).
|
||||
* ``lc``: Number of literal context bits.
|
||||
* ``lp``: Number of literal position bits. The sum ``lc + lp`` must be at
|
||||
most 4.
|
||||
|
|
|
@ -2329,7 +2329,7 @@ These functions are all available on Linux only.
|
|||
.. data:: XATTR_SIZE_MAX
|
||||
|
||||
The maximum size the value of an extended attribute can be. Currently, this
|
||||
is 64 kilobytes on Linux.
|
||||
is 64 KiB on Linux.
|
||||
|
||||
|
||||
.. data:: XATTR_CREATE
|
||||
|
|
|
@ -37,7 +37,7 @@ Large File Support
|
|||
.. sectionauthor:: Steve Clift <clift@mail.anacapa.net>
|
||||
|
||||
Several operating systems (including AIX, HP-UX, Irix and Solaris) provide
|
||||
support for files that are larger than 2 GB from a C programming model where
|
||||
support for files that are larger than 2 GiB from a C programming model where
|
||||
:c:type:`int` and :c:type:`long` are 32-bit values. This is typically accomplished
|
||||
by defining the relevant size and offset types as 64-bit values. Such files are
|
||||
sometimes referred to as :dfn:`large files`.
|
||||
|
|
|
@ -669,11 +669,11 @@ There are three tar formats that can be created with the :mod:`tarfile` module:
|
|||
|
||||
* The POSIX.1-1988 ustar format (:const:`USTAR_FORMAT`). It supports filenames
|
||||
up to a length of at best 256 characters and linknames up to 100 characters. The
|
||||
maximum file size is 8 gigabytes. This is an old and limited but widely
|
||||
maximum file size is 8 GiB. This is an old and limited but widely
|
||||
supported format.
|
||||
|
||||
* The GNU tar format (:const:`GNU_FORMAT`). It supports long filenames and
|
||||
linknames, files bigger than 8 gigabytes and sparse files. It is the de facto
|
||||
linknames, files bigger than 8 GiB and sparse files. It is the de facto
|
||||
standard on GNU/Linux systems. :mod:`tarfile` fully supports the GNU tar
|
||||
extensions for long names, sparse file support is read-only.
|
||||
|
||||
|
|
|
@ -80,15 +80,15 @@ This module defines the following functions:
|
|||
Return the thread stack size used when creating new threads. The optional
|
||||
*size* argument specifies the stack size to be used for subsequently created
|
||||
threads, and must be 0 (use platform or configured default) or a positive
|
||||
integer value of at least 32,768 (32kB). If changing the thread stack size is
|
||||
integer value of at least 32,768 (32 KiB). If changing the thread stack size is
|
||||
unsupported, a :exc:`RuntimeError` is raised. If the specified stack size is
|
||||
invalid, a :exc:`ValueError` is raised and the stack size is unmodified. 32kB
|
||||
invalid, a :exc:`ValueError` is raised and the stack size is unmodified. 32 KiB
|
||||
is currently the minimum supported stack size value to guarantee sufficient
|
||||
stack space for the interpreter itself. Note that some platforms may have
|
||||
particular restrictions on values for the stack size, such as requiring a
|
||||
minimum stack size > 32kB or requiring allocation in multiples of the system
|
||||
minimum stack size > 32 KiB or requiring allocation in multiples of the system
|
||||
memory page size - platform documentation should be referred to for more
|
||||
information (4kB pages are common; using multiples of 4096 for the stack size is
|
||||
information (4 KiB pages are common; using multiples of 4096 for the stack size is
|
||||
the suggested approach in the absence of more specific information).
|
||||
Availability: Windows, systems with POSIX threads.
|
||||
|
||||
|
|
|
@ -18,7 +18,7 @@ defined in `PKZIP Application Note
|
|||
|
||||
This module does not currently handle multi-disk ZIP files.
|
||||
It can handle ZIP files that use the ZIP64 extensions
|
||||
(that is ZIP files that are more than 4 GByte in size). It supports
|
||||
(that is ZIP files that are more than 4 GiB in size). It supports
|
||||
decryption of encrypted files in ZIP archives, but it currently cannot
|
||||
create an encrypted file. Decryption is extremely slow as it is
|
||||
implemented in native Python rather than C.
|
||||
|
@ -148,7 +148,7 @@ ZipFile Objects
|
|||
(:mod:`zlib`, :mod:`bz2` or :mod:`lzma`) is not available, :exc:`RuntimeError`
|
||||
is also raised. The default is :const:`ZIP_STORED`. If *allowZip64* is
|
||||
``True`` zipfile will create ZIP files that use the ZIP64 extensions when
|
||||
the zipfile is larger than 2 GB. If it is false (the default) :mod:`zipfile`
|
||||
the zipfile is larger than 2 GiB. If it is false (the default) :mod:`zipfile`
|
||||
will raise an exception when the ZIP file would require ZIP64 extensions.
|
||||
ZIP64 extensions are disabled by default because the default :program:`zip`
|
||||
and :program:`unzip` commands on Unix (the InfoZIP utilities) don't support
|
||||
|
|
|
@ -1788,7 +1788,7 @@ save_bytes(PicklerObject *self, PyObject *obj)
|
|||
}
|
||||
else {
|
||||
PyErr_SetString(PyExc_OverflowError,
|
||||
"cannot serialize a bytes object larger than 4GB");
|
||||
"cannot serialize a bytes object larger than 4 GiB");
|
||||
return -1; /* string too large */
|
||||
}
|
||||
|
||||
|
@ -1888,7 +1888,7 @@ save_unicode(PicklerObject *self, PyObject *obj)
|
|||
size = PyBytes_GET_SIZE(encoded);
|
||||
if (size > 0xffffffffL) {
|
||||
PyErr_SetString(PyExc_OverflowError,
|
||||
"cannot serialize a string larger than 4GB");
|
||||
"cannot serialize a string larger than 4 GiB");
|
||||
goto error; /* string too large */
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in New Issue