[2] | 1 | .. _glossary:
|
---|
| 2 |
|
---|
| 3 | ********
|
---|
| 4 | Glossary
|
---|
| 5 | ********
|
---|
| 6 |
|
---|
| 7 | .. if you add new entries, keep the alphabetical sorting!
|
---|
| 8 |
|
---|
| 9 | .. glossary::
|
---|
| 10 |
|
---|
| 11 | ``>>>``
|
---|
| 12 | The default Python prompt of the interactive shell. Often seen for code
|
---|
| 13 | examples which can be executed interactively in the interpreter.
|
---|
| 14 |
|
---|
| 15 | ``...``
|
---|
| 16 | The default Python prompt of the interactive shell when entering code for
|
---|
| 17 | an indented code block or within a pair of matching left and right
|
---|
| 18 | delimiters (parentheses, square brackets or curly braces).
|
---|
| 19 |
|
---|
| 20 | 2to3
|
---|
| 21 | A tool that tries to convert Python 2.x code to Python 3.x code by
|
---|
[391] | 22 | handling most of the incompatibilities which can be detected by parsing the
|
---|
[2] | 23 | source and traversing the parse tree.
|
---|
| 24 |
|
---|
| 25 | 2to3 is available in the standard library as :mod:`lib2to3`; a standalone
|
---|
| 26 | entry point is provided as :file:`Tools/scripts/2to3`. See
|
---|
| 27 | :ref:`2to3-reference`.
|
---|
| 28 |
|
---|
| 29 | abstract base class
|
---|
[391] | 30 | Abstract base classes complement :term:`duck-typing` by
|
---|
[2] | 31 | providing a way to define interfaces when other techniques like
|
---|
[391] | 32 | :func:`hasattr` would be clumsy or subtly wrong (for example with
|
---|
| 33 | :ref:`magic methods <new-style-special-lookup>`). ABCs introduce virtual
|
---|
| 34 | subclasses, which are classes that don't inherit from a class but are
|
---|
| 35 | still recognized by :func:`isinstance` and :func:`issubclass`; see the
|
---|
| 36 | :mod:`abc` module documentation. Python comes with many built-in ABCs for
|
---|
[2] | 37 | data structures (in the :mod:`collections` module), numbers (in the
|
---|
| 38 | :mod:`numbers` module), and streams (in the :mod:`io` module). You can
|
---|
[391] | 39 | create your own ABCs with the :mod:`abc` module.
|
---|
[2] | 40 |
|
---|
| 41 | argument
|
---|
[391] | 42 | A value passed to a :term:`function` (or :term:`method`) when calling the
|
---|
| 43 | function. There are two types of arguments:
|
---|
[2] | 44 |
|
---|
[391] | 45 | * :dfn:`keyword argument`: an argument preceded by an identifier (e.g.
|
---|
| 46 | ``name=``) in a function call or passed as a value in a dictionary
|
---|
| 47 | preceded by ``**``. For example, ``3`` and ``5`` are both keyword
|
---|
| 48 | arguments in the following calls to :func:`complex`::
|
---|
[2] | 49 |
|
---|
[391] | 50 | complex(real=3, imag=5)
|
---|
| 51 | complex(**{'real': 3, 'imag': 5})
|
---|
| 52 |
|
---|
| 53 | * :dfn:`positional argument`: an argument that is not a keyword argument.
|
---|
| 54 | Positional arguments can appear at the beginning of an argument list
|
---|
| 55 | and/or be passed as elements of an :term:`iterable` preceded by ``*``.
|
---|
| 56 | For example, ``3`` and ``5`` are both positional arguments in the
|
---|
| 57 | following calls::
|
---|
| 58 |
|
---|
| 59 | complex(3, 5)
|
---|
| 60 | complex(*(3, 5))
|
---|
| 61 |
|
---|
| 62 | Arguments are assigned to the named local variables in a function body.
|
---|
| 63 | See the :ref:`calls` section for the rules governing this assignment.
|
---|
| 64 | Syntactically, any expression can be used to represent an argument; the
|
---|
| 65 | evaluated value is assigned to the local variable.
|
---|
| 66 |
|
---|
| 67 | See also the :term:`parameter` glossary entry and the FAQ question on
|
---|
| 68 | :ref:`the difference between arguments and parameters
|
---|
| 69 | <faq-argument-vs-parameter>`.
|
---|
| 70 |
|
---|
[2] | 71 | attribute
|
---|
| 72 | A value associated with an object which is referenced by name using
|
---|
| 73 | dotted expressions. For example, if an object *o* has an attribute
|
---|
| 74 | *a* it would be referenced as *o.a*.
|
---|
| 75 |
|
---|
| 76 | BDFL
|
---|
| 77 | Benevolent Dictator For Life, a.k.a. `Guido van Rossum
|
---|
| 78 | <http://www.python.org/~guido/>`_, Python's creator.
|
---|
| 79 |
|
---|
[391] | 80 | bytes-like object
|
---|
| 81 | An object that supports the :ref:`buffer protocol <bufferobjects>`,
|
---|
| 82 | like :class:`str`, :class:`bytearray` or :class:`memoryview`.
|
---|
| 83 | Bytes-like objects can be used for various operations that expect
|
---|
| 84 | binary data, such as compression, saving to a binary file or sending
|
---|
| 85 | over a socket. Some operations need the binary data to be mutable,
|
---|
| 86 | in which case not all bytes-like objects can apply.
|
---|
| 87 |
|
---|
[2] | 88 | bytecode
|
---|
| 89 | Python source code is compiled into bytecode, the internal representation
|
---|
[391] | 90 | of a Python program in the CPython interpreter. The bytecode is also
|
---|
| 91 | cached in ``.pyc`` and ``.pyo`` files so that executing the same file is
|
---|
| 92 | faster the second time (recompilation from source to bytecode can be
|
---|
| 93 | avoided). This "intermediate language" is said to run on a
|
---|
| 94 | :term:`virtual machine` that executes the machine code corresponding to
|
---|
| 95 | each bytecode. Do note that bytecodes are not expected to work between
|
---|
| 96 | different Python virtual machines, nor to be stable between Python
|
---|
| 97 | releases.
|
---|
[2] | 98 |
|
---|
[391] | 99 | A list of bytecode instructions can be found in the documentation for
|
---|
| 100 | :ref:`the dis module <bytecodes>`.
|
---|
| 101 |
|
---|
[2] | 102 | class
|
---|
| 103 | A template for creating user-defined objects. Class definitions
|
---|
| 104 | normally contain method definitions which operate on instances of the
|
---|
| 105 | class.
|
---|
| 106 |
|
---|
| 107 | classic class
|
---|
| 108 | Any class which does not inherit from :class:`object`. See
|
---|
[391] | 109 | :term:`new-style class`. Classic classes have been removed in Python 3.
|
---|
[2] | 110 |
|
---|
| 111 | coercion
|
---|
| 112 | The implicit conversion of an instance of one type to another during an
|
---|
| 113 | operation which involves two arguments of the same type. For example,
|
---|
| 114 | ``int(3.15)`` converts the floating point number to the integer ``3``, but
|
---|
| 115 | in ``3+4.5``, each argument is of a different type (one int, one float),
|
---|
| 116 | and both must be converted to the same type before they can be added or it
|
---|
| 117 | will raise a ``TypeError``. Coercion between two operands can be
|
---|
| 118 | performed with the ``coerce`` built-in function; thus, ``3+4.5`` is
|
---|
| 119 | equivalent to calling ``operator.add(*coerce(3, 4.5))`` and results in
|
---|
| 120 | ``operator.add(3.0, 4.5)``. Without coercion, all arguments of even
|
---|
| 121 | compatible types would have to be normalized to the same value by the
|
---|
| 122 | programmer, e.g., ``float(3)+4.5`` rather than just ``3+4.5``.
|
---|
| 123 |
|
---|
| 124 | complex number
|
---|
| 125 | An extension of the familiar real number system in which all numbers are
|
---|
| 126 | expressed as a sum of a real part and an imaginary part. Imaginary
|
---|
| 127 | numbers are real multiples of the imaginary unit (the square root of
|
---|
| 128 | ``-1``), often written ``i`` in mathematics or ``j`` in
|
---|
| 129 | engineering. Python has built-in support for complex numbers, which are
|
---|
| 130 | written with this latter notation; the imaginary part is written with a
|
---|
| 131 | ``j`` suffix, e.g., ``3+1j``. To get access to complex equivalents of the
|
---|
| 132 | :mod:`math` module, use :mod:`cmath`. Use of complex numbers is a fairly
|
---|
| 133 | advanced mathematical feature. If you're not aware of a need for them,
|
---|
| 134 | it's almost certain you can safely ignore them.
|
---|
| 135 |
|
---|
| 136 | context manager
|
---|
| 137 | An object which controls the environment seen in a :keyword:`with`
|
---|
| 138 | statement by defining :meth:`__enter__` and :meth:`__exit__` methods.
|
---|
| 139 | See :pep:`343`.
|
---|
| 140 |
|
---|
| 141 | CPython
|
---|
[391] | 142 | The canonical implementation of the Python programming language, as
|
---|
| 143 | distributed on `python.org <http://python.org>`_. The term "CPython"
|
---|
| 144 | is used when necessary to distinguish this implementation from others
|
---|
| 145 | such as Jython or IronPython.
|
---|
[2] | 146 |
|
---|
| 147 | decorator
|
---|
| 148 | A function returning another function, usually applied as a function
|
---|
| 149 | transformation using the ``@wrapper`` syntax. Common examples for
|
---|
| 150 | decorators are :func:`classmethod` and :func:`staticmethod`.
|
---|
| 151 |
|
---|
| 152 | The decorator syntax is merely syntactic sugar, the following two
|
---|
| 153 | function definitions are semantically equivalent::
|
---|
| 154 |
|
---|
| 155 | def f(...):
|
---|
| 156 | ...
|
---|
| 157 | f = staticmethod(f)
|
---|
| 158 |
|
---|
| 159 | @staticmethod
|
---|
| 160 | def f(...):
|
---|
| 161 | ...
|
---|
| 162 |
|
---|
[391] | 163 | The same concept exists for classes, but is less commonly used there. See
|
---|
| 164 | the documentation for :ref:`function definitions <function>` and
|
---|
| 165 | :ref:`class definitions <class>` for more about decorators.
|
---|
[2] | 166 |
|
---|
| 167 | descriptor
|
---|
| 168 | Any *new-style* object which defines the methods :meth:`__get__`,
|
---|
| 169 | :meth:`__set__`, or :meth:`__delete__`. When a class attribute is a
|
---|
| 170 | descriptor, its special binding behavior is triggered upon attribute
|
---|
| 171 | lookup. Normally, using *a.b* to get, set or delete an attribute looks up
|
---|
| 172 | the object named *b* in the class dictionary for *a*, but if *b* is a
|
---|
| 173 | descriptor, the respective descriptor method gets called. Understanding
|
---|
| 174 | descriptors is a key to a deep understanding of Python because they are
|
---|
| 175 | the basis for many features including functions, methods, properties,
|
---|
| 176 | class methods, static methods, and reference to super classes.
|
---|
| 177 |
|
---|
| 178 | For more information about descriptors' methods, see :ref:`descriptors`.
|
---|
| 179 |
|
---|
| 180 | dictionary
|
---|
[391] | 181 | An associative array, where arbitrary keys are mapped to values. The
|
---|
| 182 | keys can be any object with :meth:`__hash__` and :meth:`__eq__` methods.
|
---|
[2] | 183 | Called a hash in Perl.
|
---|
| 184 |
|
---|
| 185 | docstring
|
---|
| 186 | A string literal which appears as the first expression in a class,
|
---|
| 187 | function or module. While ignored when the suite is executed, it is
|
---|
| 188 | recognized by the compiler and put into the :attr:`__doc__` attribute
|
---|
| 189 | of the enclosing class, function or module. Since it is available via
|
---|
| 190 | introspection, it is the canonical place for documentation of the
|
---|
| 191 | object.
|
---|
| 192 |
|
---|
| 193 | duck-typing
|
---|
[391] | 194 | A programming style which does not look at an object's type to determine
|
---|
| 195 | if it has the right interface; instead, the method or attribute is simply
|
---|
| 196 | called or used ("If it looks like a duck and quacks like a duck, it
|
---|
[2] | 197 | must be a duck.") By emphasizing interfaces rather than specific types,
|
---|
| 198 | well-designed code improves its flexibility by allowing polymorphic
|
---|
| 199 | substitution. Duck-typing avoids tests using :func:`type` or
|
---|
[391] | 200 | :func:`isinstance`. (Note, however, that duck-typing can be complemented
|
---|
| 201 | with :term:`abstract base classes <abstract base class>`.) Instead, it
|
---|
| 202 | typically employs :func:`hasattr` tests or :term:`EAFP` programming.
|
---|
[2] | 203 |
|
---|
| 204 | EAFP
|
---|
| 205 | Easier to ask for forgiveness than permission. This common Python coding
|
---|
| 206 | style assumes the existence of valid keys or attributes and catches
|
---|
| 207 | exceptions if the assumption proves false. This clean and fast style is
|
---|
| 208 | characterized by the presence of many :keyword:`try` and :keyword:`except`
|
---|
| 209 | statements. The technique contrasts with the :term:`LBYL` style
|
---|
| 210 | common to many other languages such as C.
|
---|
| 211 |
|
---|
| 212 | expression
|
---|
| 213 | A piece of syntax which can be evaluated to some value. In other words,
|
---|
[391] | 214 | an expression is an accumulation of expression elements like literals,
|
---|
| 215 | names, attribute access, operators or function calls which all return a
|
---|
| 216 | value. In contrast to many other languages, not all language constructs
|
---|
| 217 | are expressions. There are also :term:`statement`\s which cannot be used
|
---|
| 218 | as expressions, such as :keyword:`print` or :keyword:`if`. Assignments
|
---|
| 219 | are also statements, not expressions.
|
---|
[2] | 220 |
|
---|
| 221 | extension module
|
---|
[391] | 222 | A module written in C or C++, using Python's C API to interact with the
|
---|
| 223 | core and with user code.
|
---|
[2] | 224 |
|
---|
[391] | 225 | file object
|
---|
| 226 | An object exposing a file-oriented API (with methods such as
|
---|
| 227 | :meth:`read()` or :meth:`write()`) to an underlying resource. Depending
|
---|
| 228 | on the way it was created, a file object can mediate access to a real
|
---|
| 229 | on-disk file or to another type of storage or communication device
|
---|
| 230 | (for example standard input/output, in-memory buffers, sockets, pipes,
|
---|
| 231 | etc.). File objects are also called :dfn:`file-like objects` or
|
---|
| 232 | :dfn:`streams`.
|
---|
| 233 |
|
---|
| 234 | There are actually three categories of file objects: raw binary files,
|
---|
| 235 | buffered binary files and text files. Their interfaces are defined in the
|
---|
| 236 | :mod:`io` module. The canonical way to create a file object is by using
|
---|
| 237 | the :func:`open` function.
|
---|
| 238 |
|
---|
| 239 | file-like object
|
---|
| 240 | A synonym for :term:`file object`.
|
---|
| 241 |
|
---|
[2] | 242 | finder
|
---|
| 243 | An object that tries to find the :term:`loader` for a module. It must
|
---|
| 244 | implement a method named :meth:`find_module`. See :pep:`302` for
|
---|
| 245 | details.
|
---|
| 246 |
|
---|
[391] | 247 | floor division
|
---|
| 248 | Mathematical division that rounds down to nearest integer. The floor
|
---|
| 249 | division operator is ``//``. For example, the expression ``11 // 4``
|
---|
| 250 | evaluates to ``2`` in contrast to the ``2.75`` returned by float true
|
---|
| 251 | division. Note that ``(-11) // 4`` is ``-3`` because that is ``-2.75``
|
---|
| 252 | rounded *downward*. See :pep:`238`.
|
---|
| 253 |
|
---|
[2] | 254 | function
|
---|
| 255 | A series of statements which returns some value to a caller. It can also
|
---|
[391] | 256 | be passed zero or more :term:`arguments <argument>` which may be used in
|
---|
| 257 | the execution of the body. See also :term:`parameter`, :term:`method`,
|
---|
| 258 | and the :ref:`function` section.
|
---|
[2] | 259 |
|
---|
| 260 | __future__
|
---|
[391] | 261 | A pseudo-module which programmers can use to enable new language features
|
---|
[2] | 262 | which are not compatible with the current interpreter. For example, the
|
---|
| 263 | expression ``11/4`` currently evaluates to ``2``. If the module in which
|
---|
| 264 | it is executed had enabled *true division* by executing::
|
---|
| 265 |
|
---|
| 266 | from __future__ import division
|
---|
| 267 |
|
---|
| 268 | the expression ``11/4`` would evaluate to ``2.75``. By importing the
|
---|
| 269 | :mod:`__future__` module and evaluating its variables, you can see when a
|
---|
| 270 | new feature was first added to the language and when it will become the
|
---|
| 271 | default::
|
---|
| 272 |
|
---|
| 273 | >>> import __future__
|
---|
| 274 | >>> __future__.division
|
---|
| 275 | _Feature((2, 2, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 8192)
|
---|
| 276 |
|
---|
| 277 | garbage collection
|
---|
| 278 | The process of freeing memory when it is not used anymore. Python
|
---|
| 279 | performs garbage collection via reference counting and a cyclic garbage
|
---|
| 280 | collector that is able to detect and break reference cycles.
|
---|
| 281 |
|
---|
[391] | 282 | .. index:: single: generator
|
---|
| 283 |
|
---|
[2] | 284 | generator
|
---|
| 285 | A function which returns an iterator. It looks like a normal function
|
---|
[391] | 286 | except that it contains :keyword:`yield` statements for producing a series
|
---|
| 287 | a values usable in a for-loop or that can be retrieved one at a time with
|
---|
| 288 | the :func:`next` function. Each :keyword:`yield` temporarily suspends
|
---|
| 289 | processing, remembering the location execution state (including local
|
---|
| 290 | variables and pending try-statements). When the generator resumes, it
|
---|
| 291 | picks-up where it left-off (in contrast to functions which start fresh on
|
---|
| 292 | every invocation).
|
---|
[2] | 293 |
|
---|
| 294 | .. index:: single: generator expression
|
---|
| 295 |
|
---|
| 296 | generator expression
|
---|
[391] | 297 | An expression that returns an iterator. It looks like a normal expression
|
---|
[2] | 298 | followed by a :keyword:`for` expression defining a loop variable, range,
|
---|
| 299 | and an optional :keyword:`if` expression. The combined expression
|
---|
| 300 | generates values for an enclosing function::
|
---|
| 301 |
|
---|
| 302 | >>> sum(i*i for i in range(10)) # sum of squares 0, 1, 4, ... 81
|
---|
| 303 | 285
|
---|
| 304 |
|
---|
| 305 | GIL
|
---|
| 306 | See :term:`global interpreter lock`.
|
---|
| 307 |
|
---|
| 308 | global interpreter lock
|
---|
[391] | 309 | The mechanism used by the :term:`CPython` interpreter to assure that
|
---|
| 310 | only one thread executes Python :term:`bytecode` at a time.
|
---|
| 311 | This simplifies the CPython implementation by making the object model
|
---|
| 312 | (including critical built-in types such as :class:`dict`) implicitly
|
---|
| 313 | safe against concurrent access. Locking the entire interpreter
|
---|
| 314 | makes it easier for the interpreter to be multi-threaded, at the
|
---|
| 315 | expense of much of the parallelism afforded by multi-processor
|
---|
| 316 | machines.
|
---|
[2] | 317 |
|
---|
[391] | 318 | However, some extension modules, either standard or third-party,
|
---|
| 319 | are designed so as to release the GIL when doing computationally-intensive
|
---|
| 320 | tasks such as compression or hashing. Also, the GIL is always released
|
---|
| 321 | when doing I/O.
|
---|
| 322 |
|
---|
| 323 | Past efforts to create a "free-threaded" interpreter (one which locks
|
---|
| 324 | shared data at a much finer granularity) have not been successful
|
---|
| 325 | because performance suffered in the common single-processor case. It
|
---|
| 326 | is believed that overcoming this performance issue would make the
|
---|
| 327 | implementation much more complicated and therefore costlier to maintain.
|
---|
| 328 |
|
---|
[2] | 329 | hashable
|
---|
| 330 | An object is *hashable* if it has a hash value which never changes during
|
---|
| 331 | its lifetime (it needs a :meth:`__hash__` method), and can be compared to
|
---|
| 332 | other objects (it needs an :meth:`__eq__` or :meth:`__cmp__` method).
|
---|
| 333 | Hashable objects which compare equal must have the same hash value.
|
---|
| 334 |
|
---|
| 335 | Hashability makes an object usable as a dictionary key and a set member,
|
---|
| 336 | because these data structures use the hash value internally.
|
---|
| 337 |
|
---|
| 338 | All of Python's immutable built-in objects are hashable, while no mutable
|
---|
| 339 | containers (such as lists or dictionaries) are. Objects which are
|
---|
| 340 | instances of user-defined classes are hashable by default; they all
|
---|
[391] | 341 | compare unequal (except with themselves), and their hash value is their
|
---|
| 342 | :func:`id`.
|
---|
[2] | 343 |
|
---|
| 344 | IDLE
|
---|
| 345 | An Integrated Development Environment for Python. IDLE is a basic editor
|
---|
| 346 | and interpreter environment which ships with the standard distribution of
|
---|
[391] | 347 | Python.
|
---|
[2] | 348 |
|
---|
| 349 | immutable
|
---|
| 350 | An object with a fixed value. Immutable objects include numbers, strings and
|
---|
| 351 | tuples. Such an object cannot be altered. A new object has to
|
---|
| 352 | be created if a different value has to be stored. They play an important
|
---|
| 353 | role in places where a constant hash value is needed, for example as a key
|
---|
| 354 | in a dictionary.
|
---|
| 355 |
|
---|
| 356 | integer division
|
---|
| 357 | Mathematical division discarding any remainder. For example, the
|
---|
| 358 | expression ``11/4`` currently evaluates to ``2`` in contrast to the
|
---|
| 359 | ``2.75`` returned by float division. Also called *floor division*.
|
---|
| 360 | When dividing two integers the outcome will always be another integer
|
---|
| 361 | (having the floor function applied to it). However, if one of the operands
|
---|
| 362 | is another numeric type (such as a :class:`float`), the result will be
|
---|
| 363 | coerced (see :term:`coercion`) to a common type. For example, an integer
|
---|
| 364 | divided by a float will result in a float value, possibly with a decimal
|
---|
| 365 | fraction. Integer division can be forced by using the ``//`` operator
|
---|
| 366 | instead of the ``/`` operator. See also :term:`__future__`.
|
---|
| 367 |
|
---|
[391] | 368 | importing
|
---|
| 369 | The process by which Python code in one module is made available to
|
---|
| 370 | Python code in another module.
|
---|
| 371 |
|
---|
[2] | 372 | importer
|
---|
| 373 | An object that both finds and loads a module; both a
|
---|
| 374 | :term:`finder` and :term:`loader` object.
|
---|
| 375 |
|
---|
| 376 | interactive
|
---|
| 377 | Python has an interactive interpreter which means you can enter
|
---|
| 378 | statements and expressions at the interpreter prompt, immediately
|
---|
| 379 | execute them and see their results. Just launch ``python`` with no
|
---|
| 380 | arguments (possibly by selecting it from your computer's main
|
---|
| 381 | menu). It is a very powerful way to test out new ideas or inspect
|
---|
| 382 | modules and packages (remember ``help(x)``).
|
---|
| 383 |
|
---|
| 384 | interpreted
|
---|
| 385 | Python is an interpreted language, as opposed to a compiled one,
|
---|
| 386 | though the distinction can be blurry because of the presence of the
|
---|
| 387 | bytecode compiler. This means that source files can be run directly
|
---|
| 388 | without explicitly creating an executable which is then run.
|
---|
| 389 | Interpreted languages typically have a shorter development/debug cycle
|
---|
| 390 | than compiled ones, though their programs generally also run more
|
---|
| 391 | slowly. See also :term:`interactive`.
|
---|
| 392 |
|
---|
| 393 | iterable
|
---|
[391] | 394 | An object capable of returning its members one at a time. Examples of
|
---|
| 395 | iterables include all sequence types (such as :class:`list`, :class:`str`,
|
---|
| 396 | and :class:`tuple`) and some non-sequence types like :class:`dict`
|
---|
| 397 | and :class:`file` and objects of any classes you define
|
---|
| 398 | with an :meth:`__iter__` or :meth:`__getitem__` method. Iterables can be
|
---|
| 399 | used in a :keyword:`for` loop and in many other places where a sequence is
|
---|
| 400 | needed (:func:`zip`, :func:`map`, ...). When an iterable object is passed
|
---|
| 401 | as an argument to the built-in function :func:`iter`, it returns an
|
---|
| 402 | iterator for the object. This iterator is good for one pass over the set
|
---|
| 403 | of values. When using iterables, it is usually not necessary to call
|
---|
| 404 | :func:`iter` or deal with iterator objects yourself. The ``for``
|
---|
[2] | 405 | statement does that automatically for you, creating a temporary unnamed
|
---|
| 406 | variable to hold the iterator for the duration of the loop. See also
|
---|
| 407 | :term:`iterator`, :term:`sequence`, and :term:`generator`.
|
---|
| 408 |
|
---|
| 409 | iterator
|
---|
| 410 | An object representing a stream of data. Repeated calls to the iterator's
|
---|
| 411 | :meth:`next` method return successive items in the stream. When no more
|
---|
| 412 | data are available a :exc:`StopIteration` exception is raised instead. At
|
---|
| 413 | this point, the iterator object is exhausted and any further calls to its
|
---|
| 414 | :meth:`next` method just raise :exc:`StopIteration` again. Iterators are
|
---|
| 415 | required to have an :meth:`__iter__` method that returns the iterator
|
---|
| 416 | object itself so every iterator is also iterable and may be used in most
|
---|
| 417 | places where other iterables are accepted. One notable exception is code
|
---|
| 418 | which attempts multiple iteration passes. A container object (such as a
|
---|
| 419 | :class:`list`) produces a fresh new iterator each time you pass it to the
|
---|
| 420 | :func:`iter` function or use it in a :keyword:`for` loop. Attempting this
|
---|
| 421 | with an iterator will just return the same exhausted iterator object used
|
---|
| 422 | in the previous iteration pass, making it appear like an empty container.
|
---|
| 423 |
|
---|
| 424 | More information can be found in :ref:`typeiter`.
|
---|
| 425 |
|
---|
[391] | 426 | key function
|
---|
| 427 | A key function or collation function is a callable that returns a value
|
---|
| 428 | used for sorting or ordering. For example, :func:`locale.strxfrm` is
|
---|
| 429 | used to produce a sort key that is aware of locale specific sort
|
---|
| 430 | conventions.
|
---|
| 431 |
|
---|
| 432 | A number of tools in Python accept key functions to control how elements
|
---|
| 433 | are ordered or grouped. They include :func:`min`, :func:`max`,
|
---|
| 434 | :func:`sorted`, :meth:`list.sort`, :func:`heapq.nsmallest`,
|
---|
| 435 | :func:`heapq.nlargest`, and :func:`itertools.groupby`.
|
---|
| 436 |
|
---|
| 437 | There are several ways to create a key function. For example. the
|
---|
| 438 | :meth:`str.lower` method can serve as a key function for case insensitive
|
---|
| 439 | sorts. Alternatively, an ad-hoc key function can be built from a
|
---|
| 440 | :keyword:`lambda` expression such as ``lambda r: (r[0], r[2])``. Also,
|
---|
| 441 | the :mod:`operator` module provides three key function constructors:
|
---|
| 442 | :func:`~operator.attrgetter`, :func:`~operator.itemgetter`, and
|
---|
| 443 | :func:`~operator.methodcaller`. See the :ref:`Sorting HOW TO
|
---|
| 444 | <sortinghowto>` for examples of how to create and use key functions.
|
---|
| 445 |
|
---|
[2] | 446 | keyword argument
|
---|
[391] | 447 | See :term:`argument`.
|
---|
[2] | 448 |
|
---|
| 449 | lambda
|
---|
| 450 | An anonymous inline function consisting of a single :term:`expression`
|
---|
| 451 | which is evaluated when the function is called. The syntax to create
|
---|
| 452 | a lambda function is ``lambda [arguments]: expression``
|
---|
| 453 |
|
---|
| 454 | LBYL
|
---|
| 455 | Look before you leap. This coding style explicitly tests for
|
---|
| 456 | pre-conditions before making calls or lookups. This style contrasts with
|
---|
| 457 | the :term:`EAFP` approach and is characterized by the presence of many
|
---|
| 458 | :keyword:`if` statements.
|
---|
| 459 |
|
---|
[391] | 460 | In a multi-threaded environment, the LBYL approach can risk introducing a
|
---|
| 461 | race condition between "the looking" and "the leaping". For example, the
|
---|
| 462 | code, ``if key in mapping: return mapping[key]`` can fail if another
|
---|
| 463 | thread removes *key* from *mapping* after the test, but before the lookup.
|
---|
| 464 | This issue can be solved with locks or by using the EAFP approach.
|
---|
| 465 |
|
---|
[2] | 466 | list
|
---|
| 467 | A built-in Python :term:`sequence`. Despite its name it is more akin
|
---|
| 468 | to an array in other languages than to a linked list since access to
|
---|
| 469 | elements are O(1).
|
---|
| 470 |
|
---|
| 471 | list comprehension
|
---|
| 472 | A compact way to process all or part of the elements in a sequence and
|
---|
| 473 | return a list with the results. ``result = ["0x%02x" % x for x in
|
---|
| 474 | range(256) if x % 2 == 0]`` generates a list of strings containing
|
---|
| 475 | even hex numbers (0x..) in the range from 0 to 255. The :keyword:`if`
|
---|
| 476 | clause is optional. If omitted, all elements in ``range(256)`` are
|
---|
| 477 | processed.
|
---|
| 478 |
|
---|
| 479 | loader
|
---|
| 480 | An object that loads a module. It must define a method named
|
---|
| 481 | :meth:`load_module`. A loader is typically returned by a
|
---|
| 482 | :term:`finder`. See :pep:`302` for details.
|
---|
| 483 |
|
---|
| 484 | mapping
|
---|
[391] | 485 | A container object that supports arbitrary key lookups and implements the
|
---|
| 486 | methods specified in the :class:`~collections.Mapping` or
|
---|
| 487 | :class:`~collections.MutableMapping`
|
---|
| 488 | :ref:`abstract base classes <collections-abstract-base-classes>`. Examples
|
---|
| 489 | include :class:`dict`, :class:`collections.defaultdict`,
|
---|
| 490 | :class:`collections.OrderedDict` and :class:`collections.Counter`.
|
---|
[2] | 491 |
|
---|
| 492 | metaclass
|
---|
| 493 | The class of a class. Class definitions create a class name, a class
|
---|
| 494 | dictionary, and a list of base classes. The metaclass is responsible for
|
---|
| 495 | taking those three arguments and creating the class. Most object oriented
|
---|
| 496 | programming languages provide a default implementation. What makes Python
|
---|
| 497 | special is that it is possible to create custom metaclasses. Most users
|
---|
| 498 | never need this tool, but when the need arises, metaclasses can provide
|
---|
| 499 | powerful, elegant solutions. They have been used for logging attribute
|
---|
| 500 | access, adding thread-safety, tracking object creation, implementing
|
---|
| 501 | singletons, and many other tasks.
|
---|
| 502 |
|
---|
| 503 | More information can be found in :ref:`metaclasses`.
|
---|
| 504 |
|
---|
| 505 | method
|
---|
| 506 | A function which is defined inside a class body. If called as an attribute
|
---|
| 507 | of an instance of that class, the method will get the instance object as
|
---|
| 508 | its first :term:`argument` (which is usually called ``self``).
|
---|
| 509 | See :term:`function` and :term:`nested scope`.
|
---|
| 510 |
|
---|
[391] | 511 | method resolution order
|
---|
| 512 | Method Resolution Order is the order in which base classes are searched
|
---|
| 513 | for a member during lookup. See `The Python 2.3 Method Resolution Order
|
---|
| 514 | <http://www.python.org/download/releases/2.3/mro/>`_.
|
---|
| 515 |
|
---|
| 516 | module
|
---|
| 517 | An object that serves as an organizational unit of Python code. Modules
|
---|
| 518 | have a namespace containing arbitrary Python objects. Modules are loaded
|
---|
| 519 | into Python by the process of :term:`importing`.
|
---|
| 520 |
|
---|
| 521 | See also :term:`package`.
|
---|
| 522 |
|
---|
| 523 | MRO
|
---|
| 524 | See :term:`method resolution order`.
|
---|
| 525 |
|
---|
[2] | 526 | mutable
|
---|
| 527 | Mutable objects can change their value but keep their :func:`id`. See
|
---|
| 528 | also :term:`immutable`.
|
---|
| 529 |
|
---|
| 530 | named tuple
|
---|
| 531 | Any tuple-like class whose indexable elements are also accessible using
|
---|
| 532 | named attributes (for example, :func:`time.localtime` returns a
|
---|
| 533 | tuple-like object where the *year* is accessible either with an
|
---|
| 534 | index such as ``t[0]`` or with a named attribute like ``t.tm_year``).
|
---|
| 535 |
|
---|
| 536 | A named tuple can be a built-in type such as :class:`time.struct_time`,
|
---|
| 537 | or it can be created with a regular class definition. A full featured
|
---|
| 538 | named tuple can also be created with the factory function
|
---|
| 539 | :func:`collections.namedtuple`. The latter approach automatically
|
---|
| 540 | provides extra features such as a self-documenting representation like
|
---|
| 541 | ``Employee(name='jones', title='programmer')``.
|
---|
| 542 |
|
---|
| 543 | namespace
|
---|
| 544 | The place where a variable is stored. Namespaces are implemented as
|
---|
| 545 | dictionaries. There are the local, global and built-in namespaces as well
|
---|
| 546 | as nested namespaces in objects (in methods). Namespaces support
|
---|
| 547 | modularity by preventing naming conflicts. For instance, the functions
|
---|
| 548 | :func:`__builtin__.open` and :func:`os.open` are distinguished by their
|
---|
| 549 | namespaces. Namespaces also aid readability and maintainability by making
|
---|
| 550 | it clear which module implements a function. For instance, writing
|
---|
| 551 | :func:`random.seed` or :func:`itertools.izip` makes it clear that those
|
---|
| 552 | functions are implemented by the :mod:`random` and :mod:`itertools`
|
---|
| 553 | modules, respectively.
|
---|
| 554 |
|
---|
| 555 | nested scope
|
---|
| 556 | The ability to refer to a variable in an enclosing definition. For
|
---|
| 557 | instance, a function defined inside another function can refer to
|
---|
| 558 | variables in the outer function. Note that nested scopes work only for
|
---|
| 559 | reference and not for assignment which will always write to the innermost
|
---|
| 560 | scope. In contrast, local variables both read and write in the innermost
|
---|
| 561 | scope. Likewise, global variables read and write to the global namespace.
|
---|
| 562 |
|
---|
| 563 | new-style class
|
---|
| 564 | Any class which inherits from :class:`object`. This includes all built-in
|
---|
| 565 | types like :class:`list` and :class:`dict`. Only new-style classes can
|
---|
[391] | 566 | use Python's newer, versatile features like :attr:`~object.__slots__`,
|
---|
[2] | 567 | descriptors, properties, and :meth:`__getattribute__`.
|
---|
| 568 |
|
---|
| 569 | More information can be found in :ref:`newstyle`.
|
---|
| 570 |
|
---|
| 571 | object
|
---|
| 572 | Any data with state (attributes or value) and defined behavior
|
---|
| 573 | (methods). Also the ultimate base class of any :term:`new-style
|
---|
| 574 | class`.
|
---|
| 575 |
|
---|
[391] | 576 | package
|
---|
| 577 | A Python :term:`module` which can contain submodules or recursively,
|
---|
| 578 | subpackages. Technically, a package is a Python module with an
|
---|
| 579 | ``__path__`` attribute.
|
---|
| 580 |
|
---|
| 581 | parameter
|
---|
| 582 | A named entity in a :term:`function` (or method) definition that
|
---|
| 583 | specifies an :term:`argument` (or in some cases, arguments) that the
|
---|
| 584 | function can accept. There are four types of parameters:
|
---|
| 585 |
|
---|
| 586 | * :dfn:`positional-or-keyword`: specifies an argument that can be passed
|
---|
| 587 | either :term:`positionally <argument>` or as a :term:`keyword argument
|
---|
| 588 | <argument>`. This is the default kind of parameter, for example *foo*
|
---|
| 589 | and *bar* in the following::
|
---|
| 590 |
|
---|
| 591 | def func(foo, bar=None): ...
|
---|
| 592 |
|
---|
| 593 | * :dfn:`positional-only`: specifies an argument that can be supplied only
|
---|
| 594 | by position. Python has no syntax for defining positional-only
|
---|
| 595 | parameters. However, some built-in functions have positional-only
|
---|
| 596 | parameters (e.g. :func:`abs`).
|
---|
| 597 |
|
---|
| 598 | * :dfn:`var-positional`: specifies that an arbitrary sequence of
|
---|
| 599 | positional arguments can be provided (in addition to any positional
|
---|
| 600 | arguments already accepted by other parameters). Such a parameter can
|
---|
| 601 | be defined by prepending the parameter name with ``*``, for example
|
---|
| 602 | *args* in the following::
|
---|
| 603 |
|
---|
| 604 | def func(*args, **kwargs): ...
|
---|
| 605 |
|
---|
| 606 | * :dfn:`var-keyword`: specifies that arbitrarily many keyword arguments
|
---|
| 607 | can be provided (in addition to any keyword arguments already accepted
|
---|
| 608 | by other parameters). Such a parameter can be defined by prepending
|
---|
| 609 | the parameter name with ``**``, for example *kwargs* in the example
|
---|
| 610 | above.
|
---|
| 611 |
|
---|
| 612 | Parameters can specify both optional and required arguments, as well as
|
---|
| 613 | default values for some optional arguments.
|
---|
| 614 |
|
---|
| 615 | See also the :term:`argument` glossary entry, the FAQ question on
|
---|
| 616 | :ref:`the difference between arguments and parameters
|
---|
| 617 | <faq-argument-vs-parameter>`, and the :ref:`function` section.
|
---|
| 618 |
|
---|
[2] | 619 | positional argument
|
---|
[391] | 620 | See :term:`argument`.
|
---|
[2] | 621 |
|
---|
| 622 | Python 3000
|
---|
[391] | 623 | Nickname for the Python 3.x release line (coined long ago when the release
|
---|
| 624 | of version 3 was something in the distant future.) This is also
|
---|
| 625 | abbreviated "Py3k".
|
---|
[2] | 626 |
|
---|
| 627 | Pythonic
|
---|
| 628 | An idea or piece of code which closely follows the most common idioms
|
---|
| 629 | of the Python language, rather than implementing code using concepts
|
---|
| 630 | common to other languages. For example, a common idiom in Python is
|
---|
| 631 | to loop over all elements of an iterable using a :keyword:`for`
|
---|
| 632 | statement. Many other languages don't have this type of construct, so
|
---|
| 633 | people unfamiliar with Python sometimes use a numerical counter instead::
|
---|
| 634 |
|
---|
| 635 | for i in range(len(food)):
|
---|
| 636 | print food[i]
|
---|
| 637 |
|
---|
| 638 | As opposed to the cleaner, Pythonic method::
|
---|
| 639 |
|
---|
| 640 | for piece in food:
|
---|
| 641 | print piece
|
---|
| 642 |
|
---|
| 643 | reference count
|
---|
| 644 | The number of references to an object. When the reference count of an
|
---|
| 645 | object drops to zero, it is deallocated. Reference counting is
|
---|
| 646 | generally not visible to Python code, but it is a key element of the
|
---|
| 647 | :term:`CPython` implementation. The :mod:`sys` module defines a
|
---|
[391] | 648 | :func:`~sys.getrefcount` function that programmers can call to return the
|
---|
[2] | 649 | reference count for a particular object.
|
---|
| 650 |
|
---|
| 651 | __slots__
|
---|
| 652 | A declaration inside a :term:`new-style class` that saves memory by
|
---|
| 653 | pre-declaring space for instance attributes and eliminating instance
|
---|
| 654 | dictionaries. Though popular, the technique is somewhat tricky to get
|
---|
| 655 | right and is best reserved for rare cases where there are large numbers of
|
---|
| 656 | instances in a memory-critical application.
|
---|
| 657 |
|
---|
| 658 | sequence
|
---|
| 659 | An :term:`iterable` which supports efficient element access using integer
|
---|
| 660 | indices via the :meth:`__getitem__` special method and defines a
|
---|
| 661 | :meth:`len` method that returns the length of the sequence.
|
---|
| 662 | Some built-in sequence types are :class:`list`, :class:`str`,
|
---|
| 663 | :class:`tuple`, and :class:`unicode`. Note that :class:`dict` also
|
---|
| 664 | supports :meth:`__getitem__` and :meth:`__len__`, but is considered a
|
---|
| 665 | mapping rather than a sequence because the lookups use arbitrary
|
---|
| 666 | :term:`immutable` keys rather than integers.
|
---|
| 667 |
|
---|
| 668 | slice
|
---|
| 669 | An object usually containing a portion of a :term:`sequence`. A slice is
|
---|
| 670 | created using the subscript notation, ``[]`` with colons between numbers
|
---|
| 671 | when several are given, such as in ``variable_name[1:3:5]``. The bracket
|
---|
| 672 | (subscript) notation uses :class:`slice` objects internally (or in older
|
---|
| 673 | versions, :meth:`__getslice__` and :meth:`__setslice__`).
|
---|
| 674 |
|
---|
| 675 | special method
|
---|
| 676 | A method that is called implicitly by Python to execute a certain
|
---|
| 677 | operation on a type, such as addition. Such methods have names starting
|
---|
| 678 | and ending with double underscores. Special methods are documented in
|
---|
| 679 | :ref:`specialnames`.
|
---|
| 680 |
|
---|
| 681 | statement
|
---|
| 682 | A statement is part of a suite (a "block" of code). A statement is either
|
---|
[391] | 683 | an :term:`expression` or one of several constructs with a keyword, such
|
---|
| 684 | as :keyword:`if`, :keyword:`while` or :keyword:`for`.
|
---|
[2] | 685 |
|
---|
[391] | 686 | struct sequence
|
---|
| 687 | A tuple with named elements. Struct sequences expose an interface similiar
|
---|
| 688 | to :term:`named tuple` in that elements can either be accessed either by
|
---|
| 689 | index or as an attribute. However, they do not have any of the named tuple
|
---|
| 690 | methods like :meth:`~collections.somenamedtuple._make` or
|
---|
| 691 | :meth:`~collections.somenamedtuple._asdict`. Examples of struct sequences
|
---|
| 692 | include :data:`sys.float_info` and the return value of :func:`os.stat`.
|
---|
| 693 |
|
---|
[2] | 694 | triple-quoted string
|
---|
| 695 | A string which is bound by three instances of either a quotation mark
|
---|
| 696 | (") or an apostrophe ('). While they don't provide any functionality
|
---|
| 697 | not available with single-quoted strings, they are useful for a number
|
---|
| 698 | of reasons. They allow you to include unescaped single and double
|
---|
| 699 | quotes within a string and they can span multiple lines without the
|
---|
| 700 | use of the continuation character, making them especially useful when
|
---|
| 701 | writing docstrings.
|
---|
| 702 |
|
---|
| 703 | type
|
---|
| 704 | The type of a Python object determines what kind of object it is; every
|
---|
| 705 | object has a type. An object's type is accessible as its
|
---|
[391] | 706 | :attr:`~instance.__class__` attribute or can be retrieved with
|
---|
| 707 | ``type(obj)``.
|
---|
[2] | 708 |
|
---|
[391] | 709 | universal newlines
|
---|
| 710 | A manner of interpreting text streams in which all of the following are
|
---|
| 711 | recognized as ending a line: the Unix end-of-line convention ``'\n'``,
|
---|
| 712 | the Windows convention ``'\r\n'``, and the old Macintosh convention
|
---|
| 713 | ``'\r'``. See :pep:`278` and :pep:`3116`, as well as
|
---|
| 714 | :func:`str.splitlines` for an additional use.
|
---|
| 715 |
|
---|
| 716 | view
|
---|
| 717 | The objects returned from :meth:`dict.viewkeys`, :meth:`dict.viewvalues`,
|
---|
| 718 | and :meth:`dict.viewitems` are called dictionary views. They are lazy
|
---|
| 719 | sequences that will see changes in the underlying dictionary. To force
|
---|
| 720 | the dictionary view to become a full list use ``list(dictview)``. See
|
---|
| 721 | :ref:`dict-views`.
|
---|
| 722 |
|
---|
[2] | 723 | virtual machine
|
---|
| 724 | A computer defined entirely in software. Python's virtual machine
|
---|
| 725 | executes the :term:`bytecode` emitted by the bytecode compiler.
|
---|
| 726 |
|
---|
| 727 | Zen of Python
|
---|
| 728 | Listing of Python design principles and philosophies that are helpful in
|
---|
| 729 | understanding and using the language. The listing can be found by typing
|
---|
| 730 | "``import this``" at the interactive prompt.
|
---|