mirror of
https://github.com/AdaCore/cpython.git
synced 2026-02-12 12:57:15 -08:00
Remove trailing whitespace.
This commit is contained in:
@@ -31,7 +31,7 @@ returning data from the target object.
|
||||
|
||||
.. index:: single: PyBufferProcs
|
||||
|
||||
More information on the buffer interface is provided in the section
|
||||
More information on the buffer interface is provided in the section
|
||||
:ref:`buffer-structs`, under the description for :ctype:`PyBufferProcs`.
|
||||
|
||||
Buffer objects are useful as a way to expose the data from another object's
|
||||
@@ -104,7 +104,7 @@ could be used to pass around structured data in its native, in-memory format.
|
||||
pointer += strides[i] * indices[i];
|
||||
if (suboffsets[i] >=0 ) {
|
||||
pointer = *((char**)pointer) + suboffsets[i];
|
||||
}
|
||||
}
|
||||
}
|
||||
return (void*)pointer;
|
||||
}
|
||||
|
||||
@@ -80,7 +80,7 @@ The following functions provide locale-independent string to number conversions.
|
||||
|
||||
See the Unix man page :manpage:`atof(2)` for details.
|
||||
|
||||
|
||||
|
||||
.. cfunction:: char * PyOS_stricmp(char *s1, char *s2)
|
||||
|
||||
Case insensitive comparison of strings. The function works almost
|
||||
|
||||
@@ -22,7 +22,7 @@ the :mod:`io` module.
|
||||
|
||||
.. warning::
|
||||
|
||||
Take care when you are mixing streams and descriptors! For more
|
||||
Take care when you are mixing streams and descriptors! For more
|
||||
information, see `the GNU C Library docs
|
||||
<http://www.gnu.org/software/libc/manual/html_node/Stream_002fDescriptor-Precautions.html#Stream_002fDescriptor-Precautions>`_.
|
||||
|
||||
|
||||
@@ -885,7 +885,7 @@ Python-level trace functions in previous versions.
|
||||
|
||||
Return a tuple of function call counts. There are constants defined for the
|
||||
positions within the tuple:
|
||||
|
||||
|
||||
+-------------------------------+-------+
|
||||
| Name | Value |
|
||||
+===============================+=======+
|
||||
@@ -911,7 +911,7 @@ Python-level trace functions in previous versions.
|
||||
+-------------------------------+-------+
|
||||
| :const:`PCALL_POP` | 10 |
|
||||
+-------------------------------+-------+
|
||||
|
||||
|
||||
:const:`PCALL_FAST_FUNCTION` means no argument tuple needs to be created.
|
||||
:const:`PCALL_FASTER_FUNCTION` means that the fast-path frame setup code is used.
|
||||
|
||||
|
||||
@@ -107,7 +107,7 @@ All integers are implemented as "long" integer objects of arbitrary size.
|
||||
retrieved from the resulting value using :cfunc:`PyLong_AsVoidPtr`.
|
||||
|
||||
|
||||
.. XXX alias PyLong_AS_LONG (for now)
|
||||
.. XXX alias PyLong_AS_LONG (for now)
|
||||
.. cfunction:: long PyLong_AsLong(PyObject *pylong)
|
||||
|
||||
.. index::
|
||||
@@ -123,7 +123,7 @@ All integers are implemented as "long" integer objects of arbitrary size.
|
||||
|
||||
Return a C :ctype:`long` representation of the contents of *pylong*. If
|
||||
*pylong* is greater than :const:`LONG_MAX`, return -1 and
|
||||
set `*overflow` to 1 (for overflow) or -1 (for underflow).
|
||||
set `*overflow` to 1 (for overflow) or -1 (for underflow).
|
||||
If an exception is set because of type errors, also return -1.
|
||||
|
||||
|
||||
|
||||
@@ -96,7 +96,7 @@ There are only a few functions special to module objects.
|
||||
|
||||
.. cfunction:: int PyModule_AddIntMacro(PyObject *module, macro)
|
||||
|
||||
Add an int constant to *module*. The name and the value are taken from
|
||||
Add an int constant to *module*. The name and the value are taken from
|
||||
*macro*. For example ``PyModule_AddConstant(module, AF_INET)`` adds the int
|
||||
constant *AF_INET* with the value of *AF_INET* to *module*.
|
||||
Return ``-1`` on error, ``0`` on success.
|
||||
|
||||
@@ -15,7 +15,7 @@ Reflection
|
||||
|
||||
Return a dictionary of the local variables in the current execution frame,
|
||||
or *NULL* if no frame is currently executing.
|
||||
|
||||
|
||||
|
||||
.. cfunction:: PyObject* PyEval_GetGlobals()
|
||||
|
||||
|
||||
@@ -143,9 +143,9 @@ Sequence Protocol
|
||||
|
||||
Return the underlying array of PyObject pointers. Assumes that *o* was returned
|
||||
by :cfunc:`PySequence_Fast` and *o* is not *NULL*.
|
||||
|
||||
|
||||
Note, if a list gets resized, the reallocation may relocate the items array.
|
||||
So, only use the underlying array pointer in contexts where the sequence
|
||||
So, only use the underlying array pointer in contexts where the sequence
|
||||
cannot change.
|
||||
|
||||
|
||||
|
||||
@@ -104,7 +104,7 @@ setup script). Indirectly provides the :class:`distutils.dist.Distribution` and
|
||||
| *package_dir* | A mapping of package to | a dictionary |
|
||||
| | directory names | |
|
||||
+--------------------+--------------------------------+-------------------------------------------------------------+
|
||||
|
||||
|
||||
|
||||
|
||||
.. function:: run_setup(script_name[, script_args=None, stop_after='run'])
|
||||
@@ -754,7 +754,7 @@ This module provides the following functions.
|
||||
standard output, otherwise do nothing.
|
||||
|
||||
.. % \subsection{Compiler-specific modules}
|
||||
.. %
|
||||
.. %
|
||||
.. % The following modules implement concrete subclasses of the abstract
|
||||
.. % \class{CCompiler} class. They should not be instantiated directly, but should
|
||||
.. % be created using \function{distutils.ccompiler.new_compiler()} factory
|
||||
@@ -858,7 +858,7 @@ Contains :class:`MWerksCompiler`, an implementation of the abstract
|
||||
Macintosh. Needs work to support CW on Windows or Mac OS X.
|
||||
|
||||
.. % \subsection{Utility modules}
|
||||
.. %
|
||||
.. %
|
||||
.. % The following modules all provide general utility functions. They haven't
|
||||
.. % all been documented yet.
|
||||
|
||||
@@ -1109,13 +1109,13 @@ other utility module.
|
||||
|
||||
For MacOS X systems the OS version reflects the minimal version on which
|
||||
binaries will run (that is, the value of ``MACOSX_DEPLOYMENT_TARGET``
|
||||
during the build of Python), not the OS version of the current system.
|
||||
during the build of Python), not the OS version of the current system.
|
||||
|
||||
For universal binary builds on MacOS X the architecture value reflects
|
||||
the univeral binary status instead of the architecture of the current
|
||||
processor. For 32-bit universal binaries the architecture is ``fat``,
|
||||
for 64-bit universal binaries the architecture is ``fat64``, and
|
||||
for 4-way universal binaries the architecture is ``universal``.
|
||||
processor. For 32-bit universal binaries the architecture is ``fat``,
|
||||
for 64-bit universal binaries the architecture is ``fat64``, and
|
||||
for 4-way universal binaries the architecture is ``universal``.
|
||||
|
||||
Examples of returned values on MacOS X:
|
||||
|
||||
@@ -1692,7 +1692,7 @@ lines, and joining lines with backslashes.
|
||||
|
||||
.. % todo
|
||||
.. % \section{Distutils Commands}
|
||||
.. %
|
||||
.. %
|
||||
.. % This part of Distutils implements the various Distutils commands, such
|
||||
.. % as \code{build}, \code{install} \&c. Each command is implemented as a
|
||||
.. % separate module, with the command name as the name of the module.
|
||||
|
||||
@@ -268,13 +268,13 @@ file winds up deep in the "build tree," in a temporary directory created by
|
||||
.. % \longprogramopt{spec-file} option; used in conjunction with
|
||||
.. % \longprogramopt{spec-only}, this gives you an opportunity to customize
|
||||
.. % the \file{.spec} file manually:
|
||||
.. %
|
||||
.. %
|
||||
.. % \ begin{verbatim}
|
||||
.. % > python setup.py bdist_rpm --spec-only
|
||||
.. % # ...edit dist/FooBar-1.0.spec
|
||||
.. % > python setup.py bdist_rpm --spec-file=dist/FooBar-1.0.spec
|
||||
.. % \ end{verbatim}
|
||||
.. %
|
||||
.. %
|
||||
.. % (Although a better way to do this is probably to override the standard
|
||||
.. % \command{bdist\_rpm} command with one that writes whatever else you want
|
||||
.. % to the \file{.spec} file.)
|
||||
@@ -334,31 +334,31 @@ The installer file will be written to the "distribution directory" --- normally
|
||||
Cross-compiling on Windows
|
||||
==========================
|
||||
|
||||
Starting with Python 2.6, distutils is capable of cross-compiling between
|
||||
Windows platforms. In practice, this means that with the correct tools
|
||||
Starting with Python 2.6, distutils is capable of cross-compiling between
|
||||
Windows platforms. In practice, this means that with the correct tools
|
||||
installed, you can use a 32bit version of Windows to create 64bit extensions
|
||||
and vice-versa.
|
||||
|
||||
To build for an alternate platform, specify the :option:`--plat-name` option
|
||||
to the build command. Valid values are currently 'win32', 'win-amd64' and
|
||||
To build for an alternate platform, specify the :option:`--plat-name` option
|
||||
to the build command. Valid values are currently 'win32', 'win-amd64' and
|
||||
'win-ia64'. For example, on a 32bit version of Windows, you could execute::
|
||||
|
||||
python setup.py build --plat-name=win-amd64
|
||||
|
||||
to build a 64bit version of your extension. The Windows Installers also
|
||||
to build a 64bit version of your extension. The Windows Installers also
|
||||
support this option, so the command::
|
||||
|
||||
python setup.py build --plat-name=win-amd64 bdist_wininst
|
||||
|
||||
would create a 64bit installation executable on your 32bit version of Windows.
|
||||
|
||||
To cross-compile, you must download the Python source code and cross-compile
|
||||
To cross-compile, you must download the Python source code and cross-compile
|
||||
Python itself for the platform you are targetting - it is not possible from a
|
||||
binary installtion of Python (as the .lib etc file for other platforms are
|
||||
not included.) In practice, this means the user of a 32 bit operating
|
||||
system will need to use Visual Studio 2008 to open the
|
||||
:file:`PCBuild/PCbuild.sln` solution in the Python source tree and build the
|
||||
"x64" configuration of the 'pythoncore' project before cross-compiling
|
||||
not included.) In practice, this means the user of a 32 bit operating
|
||||
system will need to use Visual Studio 2008 to open the
|
||||
:file:`PCBuild/PCbuild.sln` solution in the Python source tree and build the
|
||||
"x64" configuration of the 'pythoncore' project before cross-compiling
|
||||
extensions is possible.
|
||||
|
||||
Note that by default, Visual Studio 2008 does not install 64bit compilers or
|
||||
|
||||
@@ -63,7 +63,7 @@ universal :option:`--help` option, e.g. ::
|
||||
--include-dirs (-I) list of directories to search for header files
|
||||
--define (-D) C preprocessor macros to define
|
||||
--undef (-U) C preprocessor macros to undefine
|
||||
--swig-opts list of SWIG command line options
|
||||
--swig-opts list of SWIG command line options
|
||||
[...]
|
||||
|
||||
Note that an option spelled :option:`--foo-bar` on the command-line is spelled
|
||||
|
||||
@@ -72,7 +72,7 @@ If you want to define another server a new section can be created::
|
||||
index-servers =
|
||||
pypi
|
||||
other
|
||||
|
||||
|
||||
[pypi]
|
||||
repository: <repository-url>
|
||||
username: <username>
|
||||
@@ -91,4 +91,4 @@ Or even with the section name::
|
||||
|
||||
python setup.py register -r other
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -213,7 +213,7 @@ This warning notwithstanding, options to SWIG can be currently passed like
|
||||
this::
|
||||
|
||||
setup(...,
|
||||
ext_modules=[Extension('_foo', ['foo.i'],
|
||||
ext_modules=[Extension('_foo', ['foo.i'],
|
||||
swig_opts=['-modern', '-I../include'])],
|
||||
py_modules=['foo'],
|
||||
)
|
||||
|
||||
@@ -508,7 +508,7 @@ in a different style:
|
||||
curly braces to indicate a "variable" part, as in ``:file:``.
|
||||
|
||||
If you don't need the "variable part" indication, use the standard
|
||||
````code```` instead.
|
||||
````code```` instead.
|
||||
|
||||
.. describe:: var
|
||||
|
||||
@@ -767,7 +767,7 @@ the definition of the symbol. There is this directive:
|
||||
don't have to escape ``*`` or ``|`` characters.
|
||||
|
||||
|
||||
.. XXX describe optional first parameter
|
||||
.. XXX describe optional first parameter
|
||||
|
||||
The following is an example taken from the Python Reference Manual::
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@ Python file, which, in the most simple case, could look like this::
|
||||
|
||||
With this :file:`setup.py`, and a file :file:`demo.c`, running ::
|
||||
|
||||
python setup.py build
|
||||
python setup.py build
|
||||
|
||||
will compile :file:`demo.c`, and produce an extension module named ``demo`` in
|
||||
the :file:`build` directory. Depending on the system, the module file will end
|
||||
|
||||
@@ -334,7 +334,7 @@ When the Python program imports module :mod:`spam` for the first time,
|
||||
:cfunc:`PyInit_spam` is called. (See below for comments about embedding Python.)
|
||||
It calls :cfunc:`PyModule_Create`, which returns a module object, and
|
||||
inserts built-in function objects into the newly created module based upon the
|
||||
table (an array of :ctype:`PyMethodDef` structures) found in the module definition.
|
||||
table (an array of :ctype:`PyMethodDef` structures) found in the module definition.
|
||||
:cfunc:`PyModule_Create` returns a pointer to the module object
|
||||
that it creates. It may abort with a fatal error for
|
||||
certain errors, or return *NULL* if the module could not be initialized
|
||||
@@ -482,7 +482,7 @@ Later, when it is time to call the function, you call the C function
|
||||
:cfunc:`PyEval_CallObject`. This function has two arguments, both pointers to
|
||||
arbitrary Python objects: the Python function, and the argument list. The
|
||||
argument list must always be a tuple object, whose length is the number of
|
||||
arguments. To call the Python function with no arguments, pass in NULL, or
|
||||
arguments. To call the Python function with no arguments, pass in NULL, or
|
||||
an empty tuple; to call it with one argument, pass a singleton tuple.
|
||||
:cfunc:`Py_BuildValue` returns a tuple when its format string consists of zero
|
||||
or more format codes between parentheses. For example::
|
||||
@@ -521,7 +521,7 @@ If this is not possible or desirable, the exception should be cleared by calling
|
||||
if (result == NULL)
|
||||
return NULL; /* Pass error back */
|
||||
...use result...
|
||||
Py_DECREF(result);
|
||||
Py_DECREF(result);
|
||||
|
||||
Depending on the desired interface to the Python callback function, you may also
|
||||
have to provide an argument list to :cfunc:`PyEval_CallObject`. In some cases
|
||||
@@ -546,7 +546,7 @@ Note the placement of ``Py_DECREF(arglist)`` immediately after the call, before
|
||||
the error check! Also note that strictly speaking this code is not complete:
|
||||
:cfunc:`Py_BuildValue` may run out of memory, and this should be checked.
|
||||
|
||||
You may also call a function with keyword arguments by using
|
||||
You may also call a function with keyword arguments by using
|
||||
:cfunc:`PyEval_CallObjectWithKeywords`. As in the above example, we use
|
||||
:cfunc:`Py_BuildValue` to construct the dictionary. ::
|
||||
|
||||
@@ -687,7 +687,7 @@ Philbrick (philbrick@hks.com)::
|
||||
|
||||
static PyObject *
|
||||
keywdarg_parrot(PyObject *self, PyObject *args, PyObject *keywds)
|
||||
{
|
||||
{
|
||||
int voltage;
|
||||
char *state = "a stiff";
|
||||
char *action = "voom";
|
||||
@@ -695,11 +695,11 @@ Philbrick (philbrick@hks.com)::
|
||||
|
||||
static char *kwlist[] = {"voltage", "state", "action", "type", NULL};
|
||||
|
||||
if (!PyArg_ParseTupleAndKeywords(args, keywds, "i|sss", kwlist,
|
||||
if (!PyArg_ParseTupleAndKeywords(args, keywds, "i|sss", kwlist,
|
||||
&voltage, &state, &action, &type))
|
||||
return NULL;
|
||||
return NULL;
|
||||
|
||||
printf("-- This parrot wouldn't %s if you put %i Volts through it.\n",
|
||||
printf("-- This parrot wouldn't %s if you put %i Volts through it.\n",
|
||||
action, voltage);
|
||||
printf("-- Lovely plumage, the %s -- It's %s!\n", type, state);
|
||||
|
||||
|
||||
@@ -1180,7 +1180,7 @@ As with the :attr:`tp_methods` table, a sentinel entry with a :attr:`name` value
|
||||
of *NULL* is required.
|
||||
|
||||
.. XXX Descriptors need to be explained in more detail somewhere, but not here.
|
||||
|
||||
|
||||
Descriptor objects have two handler functions which correspond to the
|
||||
\member{tp_getattro} and \member{tp_setattro} handlers. The
|
||||
\method{__get__()} handler is a function which is passed the descriptor,
|
||||
@@ -1233,15 +1233,15 @@ example that simply raises an exception; if this were really all you wanted, the
|
||||
return -1;
|
||||
}
|
||||
|
||||
.. XXX tp_compare is dead; need to rewrite for tp_richcompare!
|
||||
.. XXX tp_compare is dead; need to rewrite for tp_richcompare!
|
||||
|
||||
Object Comparison
|
||||
-----------------
|
||||
|
||||
|
||||
::
|
||||
|
||||
|
||||
cmpfunc tp_compare;
|
||||
|
||||
|
||||
The :attr:`tp_compare` handler is called when comparisons are needed and the
|
||||
object does not implement the specific rich comparison method which matches the
|
||||
requested comparison. (It is always used if defined and the
|
||||
@@ -1252,18 +1252,18 @@ example that simply raises an exception; if this were really all you wanted, the
|
||||
allowed to return arbitrary negative or positive integers for less than and
|
||||
greater than, respectively; as of Python 2.2, this is no longer allowed. In the
|
||||
future, other return values may be assigned a different meaning.)
|
||||
|
||||
|
||||
A :attr:`tp_compare` handler may raise an exception. In this case it should
|
||||
return a negative value. The caller has to test for the exception using
|
||||
:cfunc:`PyErr_Occurred`.
|
||||
|
||||
|
||||
Here is a sample implementation::
|
||||
|
||||
|
||||
static int
|
||||
newdatatype_compare(newdatatypeobject * obj1, newdatatypeobject * obj2)
|
||||
{
|
||||
long result;
|
||||
|
||||
|
||||
if (obj1->obj_UnderlyingDatatypePtr->size <
|
||||
obj2->obj_UnderlyingDatatypePtr->size) {
|
||||
result = -1;
|
||||
|
||||
@@ -102,7 +102,7 @@ described here are distributed with the Python sources in the
|
||||
and it should call :cfunc:`Py_InitModule` with the string ``"spam"`` as its
|
||||
first argument (use the minimal :file:`example.c` in this directory as a guide).
|
||||
By convention, it lives in a file called :file:`spam.c` or :file:`spammodule.c`.
|
||||
The output file should be called :file:`spam.pyd` (in Release mode) or
|
||||
The output file should be called :file:`spam.pyd` (in Release mode) or
|
||||
:file:`spam_d.pyd` (in Debug mode). The extension :file:`.pyd` was chosen
|
||||
to avoid confusion with a system library :file:`spam.dll` to which your module
|
||||
could be a Python interface.
|
||||
|
||||
@@ -11,7 +11,7 @@ Glossary
|
||||
``>>>``
|
||||
The default Python prompt of the interactive shell. Often seen for code
|
||||
examples which can be executed interactively in the interpreter.
|
||||
|
||||
|
||||
``...``
|
||||
The default Python prompt of the interactive shell when entering code for
|
||||
an indented code block or within a pair of matching left and right
|
||||
@@ -50,11 +50,11 @@ Glossary
|
||||
A value associated with an object which is referenced by name using
|
||||
dotted expressions. For example, if an object *o* has an attribute
|
||||
*a* it would be referenced as *o.a*.
|
||||
|
||||
|
||||
BDFL
|
||||
Benevolent Dictator For Life, a.k.a. `Guido van Rossum
|
||||
<http://www.python.org/~guido/>`_, Python's creator.
|
||||
|
||||
|
||||
bytecode
|
||||
Python source code is compiled into bytecode, the internal representation
|
||||
of a Python program in the interpreter. The bytecode is also cached in
|
||||
@@ -67,7 +67,7 @@ Glossary
|
||||
A template for creating user-defined objects. Class definitions
|
||||
normally contain method definitions which operate on instances of the
|
||||
class.
|
||||
|
||||
|
||||
coercion
|
||||
The implicit conversion of an instance of one type to another during an
|
||||
operation which involves two arguments of the same type. For example,
|
||||
@@ -77,7 +77,7 @@ Glossary
|
||||
will raise a ``TypeError``. Without coercion, all arguments of even
|
||||
compatible types would have to be normalized to the same value by the
|
||||
programmer, e.g., ``float(3)+4.5`` rather than just ``3+4.5``.
|
||||
|
||||
|
||||
complex number
|
||||
An extension of the familiar real number system in which all numbers are
|
||||
expressed as a sum of a real part and an imaginary part. Imaginary
|
||||
@@ -89,7 +89,7 @@ Glossary
|
||||
:mod:`math` module, use :mod:`cmath`. Use of complex numbers is a fairly
|
||||
advanced mathematical feature. If you're not aware of a need for them,
|
||||
it's almost certain you can safely ignore them.
|
||||
|
||||
|
||||
context manager
|
||||
An object which controls the environment seen in a :keyword:`with`
|
||||
statement by defining :meth:`__enter__` and :meth:`__exit__` methods.
|
||||
@@ -132,7 +132,7 @@ Glossary
|
||||
and reference to super classes.
|
||||
|
||||
For more information about descriptors' methods, see :ref:`descriptors`.
|
||||
|
||||
|
||||
dictionary
|
||||
An associative array, where arbitrary keys are mapped to values. The use
|
||||
of :class:`dict` closely resembles that for :class:`list`, but the keys can
|
||||
@@ -146,8 +146,8 @@ Glossary
|
||||
of the enclosing class, function or module. Since it is available via
|
||||
introspection, it is the canonical place for documentation of the
|
||||
object.
|
||||
|
||||
duck-typing
|
||||
|
||||
duck-typing
|
||||
A pythonic programming style which determines an object's type by inspection
|
||||
of its method or attribute signature rather than by explicit relationship
|
||||
to some type object ("If it looks like a duck and quacks like a duck, it
|
||||
@@ -157,13 +157,13 @@ Glossary
|
||||
:func:`isinstance`. (Note, however, that duck-typing can be complemented
|
||||
with abstract base classes.) Instead, it typically employs :func:`hasattr`
|
||||
tests or :term:`EAFP` programming.
|
||||
|
||||
|
||||
EAFP
|
||||
Easier to ask for forgiveness than permission. This common Python coding
|
||||
style assumes the existence of valid keys or attributes and catches
|
||||
exceptions if the assumption proves false. This clean and fast style is
|
||||
characterized by the presence of many :keyword:`try` and :keyword:`except`
|
||||
statements. The technique contrasts with the :term:`LBYL` style
|
||||
statements. The technique contrasts with the :term:`LBYL` style
|
||||
common to many other languages such as C.
|
||||
|
||||
expression
|
||||
@@ -196,7 +196,7 @@ Glossary
|
||||
By importing the :mod:`__future__` module and evaluating its variables,
|
||||
you can see when a new feature was first added to the language and when it
|
||||
becomes the default::
|
||||
|
||||
|
||||
>>> import __future__
|
||||
>>> __future__.division
|
||||
_Feature((2, 2, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 8192)
|
||||
@@ -205,7 +205,7 @@ Glossary
|
||||
The process of freeing memory when it is not used anymore. Python
|
||||
performs garbage collection via reference counting and a cyclic garbage
|
||||
collector that is able to detect and break reference cycles.
|
||||
|
||||
|
||||
generator
|
||||
A function which returns an iterator. It looks like a normal function
|
||||
except that values are returned to the caller using a :keyword:`yield`
|
||||
@@ -215,21 +215,21 @@ Glossary
|
||||
stopped at the :keyword:`yield` keyword (returning the result) and is
|
||||
resumed there when the next element is requested by calling the
|
||||
:meth:`__next__` method of the returned iterator.
|
||||
|
||||
|
||||
.. index:: single: generator expression
|
||||
|
||||
|
||||
generator expression
|
||||
An expression that returns a generator. It looks like a normal expression
|
||||
followed by a :keyword:`for` expression defining a loop variable, range,
|
||||
and an optional :keyword:`if` expression. The combined expression
|
||||
generates values for an enclosing function::
|
||||
|
||||
|
||||
>>> sum(i*i for i in range(10)) # sum of squares 0, 1, 4, ... 81
|
||||
285
|
||||
|
||||
|
||||
GIL
|
||||
See :term:`global interpreter lock`.
|
||||
|
||||
|
||||
global interpreter lock
|
||||
The lock used by Python threads to assure that only one thread
|
||||
executes in the :term:`CPython` :term:`virtual machine` at a time.
|
||||
@@ -255,14 +255,14 @@ Glossary
|
||||
containers (such as lists or dictionaries) are. Objects which are
|
||||
instances of user-defined classes are hashable by default; they all
|
||||
compare unequal, and their hash value is their :func:`id`.
|
||||
|
||||
|
||||
IDLE
|
||||
An Integrated Development Environment for Python. IDLE is a basic editor
|
||||
and interpreter environment which ships with the standard distribution of
|
||||
Python. Good for beginners, it also serves as clear example code for
|
||||
those wanting to implement a moderately sophisticated, multi-platform GUI
|
||||
application.
|
||||
|
||||
|
||||
immutable
|
||||
An object with a fixed value. Immutable objects include numbers, strings and
|
||||
tuples. Such an object cannot be altered. A new object has to
|
||||
@@ -277,7 +277,7 @@ Glossary
|
||||
arguments (possibly by selecting it from your computer's main
|
||||
menu). It is a very powerful way to test out new ideas or inspect
|
||||
modules and packages (remember ``help(x)``).
|
||||
|
||||
|
||||
interpreted
|
||||
Python is an interpreted language, as opposed to a compiled one,
|
||||
though the distinction can be blurry because of the presence of the
|
||||
@@ -286,7 +286,7 @@ Glossary
|
||||
Interpreted languages typically have a shorter development/debug cycle
|
||||
than compiled ones, though their programs generally also run more
|
||||
slowly. See also :term:`interactive`.
|
||||
|
||||
|
||||
iterable
|
||||
A container object capable of returning its members one at a
|
||||
time. Examples of iterables include all sequence types (such as
|
||||
@@ -302,7 +302,7 @@ Glossary
|
||||
statement does that automatically for you, creating a temporary unnamed
|
||||
variable to hold the iterator for the duration of the loop. See also
|
||||
:term:`iterator`, :term:`sequence`, and :term:`generator`.
|
||||
|
||||
|
||||
iterator
|
||||
An object representing a stream of data. Repeated calls to the iterator's
|
||||
:meth:`__next__` (or passing it to the builtin function) :func:`next`
|
||||
@@ -318,7 +318,7 @@ Glossary
|
||||
:func:`iter` function or use it in a :keyword:`for` loop. Attempting this
|
||||
with an iterator will just return the same exhausted iterator object used
|
||||
in the previous iteration pass, making it appear like an empty container.
|
||||
|
||||
|
||||
More information can be found in :ref:`typeiter`.
|
||||
|
||||
keyword argument
|
||||
@@ -342,7 +342,7 @@ Glossary
|
||||
A built-in Python :term:`sequence`. Despite its name it is more akin
|
||||
to an array in other languages than to a linked list since access to
|
||||
elements are O(1).
|
||||
|
||||
|
||||
list comprehension
|
||||
A compact way to process all or part of the elements in a sequence and
|
||||
return a list with the results. ``result = ["0x%02x" % x for x in
|
||||
@@ -350,11 +350,11 @@ Glossary
|
||||
even hex numbers (0x..) in the range from 0 to 255. The :keyword:`if`
|
||||
clause is optional. If omitted, all elements in ``range(256)`` are
|
||||
processed.
|
||||
|
||||
|
||||
mapping
|
||||
A container object (such as :class:`dict`) which supports arbitrary key
|
||||
lookups using the special method :meth:`__getitem__`.
|
||||
|
||||
|
||||
metaclass
|
||||
The class of a class. Class definitions create a class name, a class
|
||||
dictionary, and a list of base classes. The metaclass is responsible for
|
||||
@@ -373,7 +373,7 @@ Glossary
|
||||
of an instance of that class, the method will get the instance object as
|
||||
its first :term:`argument` (which is usually called ``self``).
|
||||
See :term:`function` and :term:`nested scope`.
|
||||
|
||||
|
||||
mutable
|
||||
Mutable objects can change their value but keep their :func:`id`. See
|
||||
also :term:`immutable`.
|
||||
@@ -390,7 +390,7 @@ Glossary
|
||||
:func:`collections.namedtuple`. The latter approach automatically
|
||||
provides extra features such as a self-documenting representation like
|
||||
``Employee(name='jones', title='programmer')``.
|
||||
|
||||
|
||||
namespace
|
||||
The place where a variable is stored. Namespaces are implemented as
|
||||
dictionaries. There are the local, global and builtin namespaces as well
|
||||
@@ -402,7 +402,7 @@ Glossary
|
||||
:func:`random.seed` or :func:`itertools.izip` makes it clear that those
|
||||
functions are implemented by the :mod:`random` and :mod:`itertools`
|
||||
modules, respectively.
|
||||
|
||||
|
||||
nested scope
|
||||
The ability to refer to a variable in an enclosing definition. For
|
||||
instance, a function defined inside another function can refer to
|
||||
@@ -410,7 +410,7 @@ Glossary
|
||||
reference and not for assignment which will always write to the innermost
|
||||
scope. In contrast, local variables both read and write in the innermost
|
||||
scope. Likewise, global variables read and write to the global namespace.
|
||||
|
||||
|
||||
new-style class
|
||||
Old name for the flavor of classes now used for all class objects. In
|
||||
earlier Python versions, only new-style classes could use Python's newer,
|
||||
@@ -421,7 +421,7 @@ Glossary
|
||||
Any data with state (attributes or value) and defined behavior
|
||||
(methods). Also the ultimate base class of any :term:`new-style
|
||||
class`.
|
||||
|
||||
|
||||
positional argument
|
||||
The arguments assigned to local names inside a function or method,
|
||||
determined by the order in which they were given in the call. ``*`` is
|
||||
@@ -441,7 +441,7 @@ Glossary
|
||||
to loop over all elements of an iterable using a :keyword:`for`
|
||||
statement. Many other languages don't have this type of construct, so
|
||||
people unfamiliar with Python sometimes use a numerical counter instead::
|
||||
|
||||
|
||||
for i in range(len(food)):
|
||||
print(food[i])
|
||||
|
||||
@@ -464,7 +464,7 @@ Glossary
|
||||
popular, the technique is somewhat tricky to get right and is best
|
||||
reserved for rare cases where there are large numbers of instances in a
|
||||
memory-critical application.
|
||||
|
||||
|
||||
sequence
|
||||
An :term:`iterable` which supports efficient element access using integer
|
||||
indices via the :meth:`__getitem__` special method and defines a
|
||||
@@ -516,7 +516,7 @@ Glossary
|
||||
virtual machine
|
||||
A computer defined entirely in software. Python's virtual machine
|
||||
executes the :term:`bytecode` emitted by the bytecode compiler.
|
||||
|
||||
|
||||
Zen of Python
|
||||
Listing of Python design principles and philosophies that are helpful in
|
||||
understanding and using the language. The listing can be found by typing
|
||||
|
||||
@@ -399,8 +399,8 @@ string. It can optionally be limited to a fixed number of characters. ::
|
||||
|
||||
curses.echo() # Enable echoing of characters
|
||||
|
||||
# Get a 15-character string, with the cursor on the top line
|
||||
s = stdscr.getstr(0,0, 15)
|
||||
# Get a 15-character string, with the cursor on the top line
|
||||
s = stdscr.getstr(0,0, 15)
|
||||
|
||||
The Python :mod:`curses.textpad` module supplies something better. With it, you
|
||||
can turn a window into a text box that supports an Emacs-like set of
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user