mirror of https://github.com/python/cpython
Many minor markup adjustments for consistency.
This commit is contained in:
parent
4d707a5d08
commit
a030c768af
|
@ -521,9 +521,9 @@ Python classes can define an \method{__iter__()} method, which should
|
||||||
create and return a new iterator for the object; if the object is its
|
create and return a new iterator for the object; if the object is its
|
||||||
own iterator, this method can just return \code{self}. In particular,
|
own iterator, this method can just return \code{self}. In particular,
|
||||||
iterators will usually be their own iterators. Extension types
|
iterators will usually be their own iterators. Extension types
|
||||||
implemented in C can implement a \code{tp_iter} function in order to
|
implemented in C can implement a \member{tp_iter} function in order to
|
||||||
return an iterator, and extension types that want to behave as
|
return an iterator, and extension types that want to behave as
|
||||||
iterators can define a \code{tp_iternext} function.
|
iterators can define a \member{tp_iternext} function.
|
||||||
|
|
||||||
So, after all this, what do iterators actually do? They have one
|
So, after all this, what do iterators actually do? They have one
|
||||||
required method, \method{next()}, which takes no arguments and returns
|
required method, \method{next()}, which takes no arguments and returns
|
||||||
|
@ -552,7 +552,7 @@ In 2.2, Python's \keyword{for} statement no longer expects a sequence;
|
||||||
it expects something for which \function{iter()} will return an iterator.
|
it expects something for which \function{iter()} will return an iterator.
|
||||||
For backward compatibility and convenience, an iterator is
|
For backward compatibility and convenience, an iterator is
|
||||||
automatically constructed for sequences that don't implement
|
automatically constructed for sequences that don't implement
|
||||||
\method{__iter__()} or a \code{tp_iter} slot, so \code{for i in
|
\method{__iter__()} or a \member{tp_iter} slot, so \code{for i in
|
||||||
[1,2,3]} will still work. Wherever the Python interpreter loops over
|
[1,2,3]} will still work. Wherever the Python interpreter loops over
|
||||||
a sequence, it's been changed to use the iterator protocol. This
|
a sequence, it's been changed to use the iterator protocol. This
|
||||||
means you can do things like this:
|
means you can do things like this:
|
||||||
|
@ -659,11 +659,11 @@ outputs the value of \code{i}, similar to a \keyword{return}
|
||||||
statement. The big difference between \keyword{yield} and a
|
statement. The big difference between \keyword{yield} and a
|
||||||
\keyword{return} statement is that on reaching a \keyword{yield} the
|
\keyword{return} statement is that on reaching a \keyword{yield} the
|
||||||
generator's state of execution is suspended and local variables are
|
generator's state of execution is suspended and local variables are
|
||||||
preserved. On the next call to the generator's \code{.next()} method,
|
preserved. On the next call to the generator's \code{next()} method,
|
||||||
the function will resume executing immediately after the
|
the function will resume executing immediately after the
|
||||||
\keyword{yield} statement. (For complicated reasons, the
|
\keyword{yield} statement. (For complicated reasons, the
|
||||||
\keyword{yield} statement isn't allowed inside the \keyword{try} block
|
\keyword{yield} statement isn't allowed inside the \keyword{try} block
|
||||||
of a \code{try...finally} statement; read \pep{255} for a full
|
of a \keyword{try}...\keyword{finally} statement; read \pep{255} for a full
|
||||||
explanation of the interaction between \keyword{yield} and
|
explanation of the interaction between \keyword{yield} and
|
||||||
exceptions.)
|
exceptions.)
|
||||||
|
|
||||||
|
@ -863,7 +863,7 @@ of \code{/} will not change until Python 3.0.
|
||||||
|
|
||||||
\item Classes can define methods called \method{__truediv__} and
|
\item Classes can define methods called \method{__truediv__} and
|
||||||
\method{__floordiv__} to overload the two division operators. At the
|
\method{__floordiv__} to overload the two division operators. At the
|
||||||
C level, there are also slots in the \code{PyNumberMethods} structure
|
C level, there are also slots in the \ctype{PyNumberMethods} structure
|
||||||
so extension types can define the two operators.
|
so extension types can define the two operators.
|
||||||
|
|
||||||
\item Python 2.2 supports some command-line arguments for testing
|
\item Python 2.2 supports some command-line arguments for testing
|
||||||
|
@ -1131,7 +1131,7 @@ more information about XML-RPC.
|
||||||
function \function{help()} that uses the \module{pydoc} module
|
function \function{help()} that uses the \module{pydoc} module
|
||||||
introduced in Python 2.1 to provide interactive help.
|
introduced in Python 2.1 to provide interactive help.
|
||||||
\code{help(\var{object})} displays any available help text about
|
\code{help(\var{object})} displays any available help text about
|
||||||
\var{object}. \code{help()} with no argument puts you in an online
|
\var{object}. \function{help()} with no argument puts you in an online
|
||||||
help utility, where you can enter the names of functions, classes,
|
help utility, where you can enter the names of functions, classes,
|
||||||
or modules to read their help text.
|
or modules to read their help text.
|
||||||
(Contributed by Guido van Rossum, using Ka-Ping Yee's \module{pydoc} module.)
|
(Contributed by Guido van Rossum, using Ka-Ping Yee's \module{pydoc} module.)
|
||||||
|
@ -1243,7 +1243,7 @@ affect you very much.
|
||||||
\cfunction{PyArg_UnpackTuple()}, has been added that's simpler and
|
\cfunction{PyArg_UnpackTuple()}, has been added that's simpler and
|
||||||
presumably faster. Instead of specifying a format string, the
|
presumably faster. Instead of specifying a format string, the
|
||||||
caller simply gives the minimum and maximum number of arguments
|
caller simply gives the minimum and maximum number of arguments
|
||||||
expected, and a set of pointers to \code{PyObject*} variables that
|
expected, and a set of pointers to \ctype{PyObject*} variables that
|
||||||
will be filled in with argument values.
|
will be filled in with argument values.
|
||||||
|
|
||||||
\item Two new flags \constant{METH_NOARGS} and \constant{METH_O} are
|
\item Two new flags \constant{METH_NOARGS} and \constant{METH_O} are
|
||||||
|
@ -1358,10 +1358,10 @@ to experiment with these modules can uncomment them manually.
|
||||||
now convert it to an MBCS encoded string, as used by the Microsoft
|
now convert it to an MBCS encoded string, as used by the Microsoft
|
||||||
file APIs. As MBCS is explicitly used by the file APIs, Python's
|
file APIs. As MBCS is explicitly used by the file APIs, Python's
|
||||||
choice of ASCII as the default encoding turns out to be an
|
choice of ASCII as the default encoding turns out to be an
|
||||||
annoyance. On Unix, the locale's character set is used if
|
annoyance. On \UNIX, the locale's character set is used if
|
||||||
\function{locale.nl_langinfo(CODESET)} is available. (Windows
|
\function{locale.nl_langinfo(CODESET)} is available. (Windows
|
||||||
support was contributed by Mark Hammond with assistance from
|
support was contributed by Mark Hammond with assistance from
|
||||||
Marc-Andr\'e Lemburg. Unix support was added by Martin von L\"owis.)
|
Marc-Andr\'e Lemburg. \UNIX{} support was added by Martin von L\"owis.)
|
||||||
|
|
||||||
\item Large file support is now enabled on Windows. (Contributed by
|
\item Large file support is now enabled on Windows. (Contributed by
|
||||||
Tim Peters.)
|
Tim Peters.)
|
||||||
|
|
Loading…
Reference in New Issue