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,
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
-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
required method, \method{next()}, which takes no arguments and returns
it expects something for which \function{iter()} will return an iterator.
For backward compatibility and convenience, an iterator is
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
a sequence, it's been changed to use the iterator protocol. This
means you can do things like this:
statement. The big difference between \keyword{yield} and a
\keyword{return} statement is that on reaching a \keyword{yield} the
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
\keyword{yield} statement. (For complicated reasons, the
\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
exceptions.)
\item Classes can define methods called \method{__truediv__} and
\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.
\item Python 2.2 supports some command-line arguments for testing
function \function{help()} that uses the \module{pydoc} module
introduced in Python 2.1 to provide interactive help.
\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,
or modules to read their help text.
(Contributed by Guido van Rossum, using Ka-Ping Yee's \module{pydoc} module.)
\cfunction{PyArg_UnpackTuple()}, has been added that's simpler and
presumably faster. Instead of specifying a format string, the
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.
\item Two new flags \constant{METH_NOARGS} and \constant{METH_O} are
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
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
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
Tim Peters.)
projects / python / commitdiff