diff options
| -rw-r--r-- | Doc/howto/unicode.rst | 4 | ||||
| -rw-r--r-- | Doc/library/_thread.rst | 8 | ||||
| -rw-r--r-- | Doc/library/lzma.rst | 6 | ||||
| -rw-r--r-- | Doc/library/os.rst | 2 | ||||
| -rw-r--r-- | Doc/library/posix.rst | 2 | ||||
| -rw-r--r-- | Doc/library/tarfile.rst | 4 | ||||
| -rw-r--r-- | Doc/library/threading.rst | 8 | ||||
| -rw-r--r-- | Doc/library/zipfile.rst | 4 | ||||
| -rw-r--r-- | Modules/_pickle.c | 4 |
9 files changed, 21 insertions, 21 deletions
diff --git a/Doc/howto/unicode.rst b/Doc/howto/unicode.rst index 7500dce..3dafc8c 100644 --- a/Doc/howto/unicode.rst +++ b/Doc/howto/unicode.rst @@ -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.) diff --git a/Doc/library/_thread.rst b/Doc/library/_thread.rst index 751c3e8..fae2781 100644 --- a/Doc/library/_thread.rst +++ b/Doc/library/_thread.rst @@ -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. diff --git a/Doc/library/lzma.rst b/Doc/library/lzma.rst index f09fa08..5fd5039 100644 --- a/Doc/library/lzma.rst +++ b/Doc/library/lzma.rst @@ -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. diff --git a/Doc/library/os.rst b/Doc/library/os.rst index 027ad70..e70c886 100644 --- a/Doc/library/os.rst +++ b/Doc/library/os.rst @@ -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 diff --git a/Doc/library/posix.rst b/Doc/library/posix.rst index 07db2b2..ba1b4b5 100644 --- a/Doc/library/posix.rst +++ b/Doc/library/posix.rst @@ -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`. diff --git a/Doc/library/tarfile.rst b/Doc/library/tarfile.rst index 86dd33d..b8b65b9 100644 --- a/Doc/library/tarfile.rst +++ b/Doc/library/tarfile.rst @@ -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. diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst index 00ae3ec..f697cbb 100644 --- a/Doc/library/threading.rst +++ b/Doc/library/threading.rst @@ -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. diff --git a/Doc/library/zipfile.rst b/Doc/library/zipfile.rst index c63b23b..75e8fd5 100644 --- a/Doc/library/zipfile.rst +++ b/Doc/library/zipfile.rst @@ -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 diff --git a/Modules/_pickle.c b/Modules/_pickle.c index c0b5cf5..c213a51 100644 --- a/Modules/_pickle.c +++ b/Modules/_pickle.c @@ -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 */ } |