Fix typos and whitespace in PEP-393.

This commit is contained in:
Ezio Melotti 2011-09-29 04:56:12 +03:00
parent 5e4bc1147e
commit e8a7d6bc87
1 changed files with 8 additions and 8 deletions

View File

@ -118,7 +118,7 @@ The fields have the following interpretations:
(implies ready)
- ascii: the object uses the PyASCIIObject representation
(implies compact and ready)
- ready: the canonical represenation is ready to be accessed through
- ready: the canonical representation is ready to be accessed through
PyUnicode_DATA and PyUnicode_GET_LENGTH. This is set either if the
object is compact, or the data pointer and length have been
initialized.
@ -160,7 +160,7 @@ Both parameters must denote the eventual size/range of the strings.
In particular, codecs using this API must compute both the number of
characters and the maximum character in advance. An string is
allocated according to the specified size and character range and is
null-terminated; the actual characters in it may be unitialized.
null-terminated; the actual characters in it may be uninitialized.
PyUnicode_FromString and PyUnicode_FromStringAndSize remain supported
for processing UTF-8 input; the input is decoded, and the UTF-8
@ -188,7 +188,7 @@ values PyUnicode_WCHAR_KIND (0), PyUnicode_1BYTE_KIND (1),
PyUnicode_2BYTE_KIND (2), or PyUnicode_4BYTE_KIND (3). PyUnicode_DATA
gives the void pointer to the data. Access to individual characters
should use PyUnicode_{READ|WRITE}[_CHAR]:
- PyUnciode_READ(kind, data, index)
- PyUnicode_WRITE(kind, data, index, value)
- PyUnicode_READ_CHAR(unicode, index)
@ -240,7 +240,7 @@ String creation functions:
Character access utility functions:
- PyUnicode_GetLength(o), PyUnicode_ReadChar(o, index),
- PyUnicode_GetLength(o), PyUnicode_ReadChar(o, index),
PyUnicode_WriteChar(o, index, character)
- PyUnicode_CopyCharacters(to, to_start, from, from_start, how_many)
- PyUnicode_FindChar(str, ch, start, end, direction)
@ -296,7 +296,7 @@ The following macros and functions are deprecated:
PyUnicode_EncodeUnicodeEscape, PyUnicode_EncodeRawUnicodeEscape,
PyUnicode_EncodeLatin1, PyUnicode_EncodeASCII,
PyUnicode_EncodeCharmap, PyUnicode_TranslateCharmap,
PyUnicode_EncodeMBCS, PyUnicode_EncodeDecimal,
PyUnicode_EncodeMBCS, PyUnicode_EncodeDecimal,
PyUnicode_TransformDecimalToASCII
- Py_UNICODE_{strlen, strcat, strcpy, strcmp, strchr, strrchr}
- PyUnicode_AsUnicodeCopy
@ -314,7 +314,7 @@ ready, and then continue accessing the (now invalid) Py_UNICODE
pointer. Such code will break with this PEP. The code was already
flawed in 3.2, as there is was no explicit guarantee that the
PyUnicode_AS_UNICODE result would stay valid after an API call (due to
the possiblity of string resizing). Modules that face this issue
the possibility of string resizing). Modules that face this issue
need to re-fetch the Py_UNICODE pointer after API calls; doing
so will continue to work correctly in earlier Python versions.
@ -395,7 +395,7 @@ characters, use indexing operations rather than pointer arithmetic;
indexing works well for PyUnicode_READ(_CHAR) and PyUnicode_WRITE. Use
void* as the buffer type for characters to let the compiler detect
invalid dereferencing operations. If you do want to use pointer
arithmentics (e.g. when converting existing code), use (unsigned)
arithmetics (e.g. when converting existing code), use (unsigned)
char* as the buffer type, and keep the element size (1, 2, or 4) in a
variable. Notice that (1<<(kind-1)) will produce the element size
given a buffer kind.
@ -428,7 +428,7 @@ maximum character.
For common tasks, direct access to the string representation may not
be necessary: PyUnicode_Find, PyUnicode_FindChar, PyUnicode_Ord, and
PyUnicode_CopyCharacters help in analyzing and creating string
objects, operating on indices instead of data pointers.
objects, operating on indexes instead of data pointers.
References
==========