1.. _glossary:
2
3********
4Glossary
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      Can refer to:
17
18      * The default Python prompt of the interactive shell when entering the
19        code for an indented code block, when within a pair of matching left and
20        right delimiters (parentheses, square brackets, curly braces or triple
21        quotes), or after specifying a decorator.
22
23      * The :const:`Ellipsis` built-in constant.
24
25   2to3
26      A tool that tries to convert Python 2.x code to Python 3.x code by
27      handling most of the incompatibilities which can be detected by parsing the
28      source and traversing the parse tree.
29
30      2to3 is available in the standard library as :mod:`lib2to3`; a standalone
31      entry point is provided as :file:`Tools/scripts/2to3`.  See
32      :ref:`2to3-reference`.
33
34   abstract base class
35      Abstract base classes complement :term:`duck-typing` by
36      providing a way to define interfaces when other techniques like
37      :func:`hasattr` would be clumsy or subtly wrong (for example with
38      :ref:`magic methods <special-lookup>`).  ABCs introduce virtual
39      subclasses, which are classes that don't inherit from a class but are
40      still recognized by :func:`isinstance` and :func:`issubclass`; see the
41      :mod:`abc` module documentation.  Python comes with many built-in ABCs for
42      data structures (in the :mod:`collections.abc` module), numbers (in the
43      :mod:`numbers` module), streams (in the :mod:`io` module), import finders
44      and loaders (in the :mod:`importlib.abc` module).  You can create your own
45      ABCs with the :mod:`abc` module.
46
47   annotation
48      A label associated with a variable, a class
49      attribute or a function parameter or return value,
50      used by convention as a :term:`type hint`.
51
52      Annotations of local variables cannot be accessed at runtime, but
53      annotations of global variables, class attributes, and functions
54      are stored in the :attr:`__annotations__`
55      special attribute of modules, classes, and functions,
56      respectively.
57
58      See :term:`variable annotation`, :term:`function annotation`, :pep:`484`
59      and :pep:`526`, which describe this functionality.
60      Also see :ref:`annotations-howto`
61      for best practices on working with annotations.
62
63   argument
64      A value passed to a :term:`function` (or :term:`method`) when calling the
65      function.  There are two kinds of argument:
66
67      * :dfn:`keyword argument`: an argument preceded by an identifier (e.g.
68        ``name=``) in a function call or passed as a value in a dictionary
69        preceded by ``**``.  For example, ``3`` and ``5`` are both keyword
70        arguments in the following calls to :func:`complex`::
71
72           complex(real=3, imag=5)
73           complex(**{'real': 3, 'imag': 5})
74
75      * :dfn:`positional argument`: an argument that is not a keyword argument.
76        Positional arguments can appear at the beginning of an argument list
77        and/or be passed as elements of an :term:`iterable` preceded by ``*``.
78        For example, ``3`` and ``5`` are both positional arguments in the
79        following calls::
80
81           complex(3, 5)
82           complex(*(3, 5))
83
84      Arguments are assigned to the named local variables in a function body.
85      See the :ref:`calls` section for the rules governing this assignment.
86      Syntactically, any expression can be used to represent an argument; the
87      evaluated value is assigned to the local variable.
88
89      See also the :term:`parameter` glossary entry, the FAQ question on
90      :ref:`the difference between arguments and parameters
91      <faq-argument-vs-parameter>`, and :pep:`362`.
92
93   asynchronous context manager
94      An object which controls the environment seen in an
95      :keyword:`async with` statement by defining :meth:`__aenter__` and
96      :meth:`__aexit__` methods.  Introduced by :pep:`492`.
97
98   asynchronous generator
99      A function which returns an :term:`asynchronous generator iterator`.  It
100      looks like a coroutine function defined with :keyword:`async def` except
101      that it contains :keyword:`yield` expressions for producing a series of
102      values usable in an :keyword:`async for` loop.
103
104      Usually refers to an asynchronous generator function, but may refer to an
105      *asynchronous generator iterator* in some contexts.  In cases where the
106      intended meaning isn't clear, using the full terms avoids ambiguity.
107
108      An asynchronous generator function may contain :keyword:`await`
109      expressions as well as :keyword:`async for`, and :keyword:`async with`
110      statements.
111
112   asynchronous generator iterator
113      An object created by a :term:`asynchronous generator` function.
114
115      This is an :term:`asynchronous iterator` which when called using the
116      :meth:`__anext__` method returns an awaitable object which will execute
117      the body of the asynchronous generator function until the next
118      :keyword:`yield` expression.
119
120      Each :keyword:`yield` temporarily suspends processing, remembering the
121      location execution state (including local variables and pending
122      try-statements).  When the *asynchronous generator iterator* effectively
123      resumes with another awaitable returned by :meth:`__anext__`, it
124      picks up where it left off.  See :pep:`492` and :pep:`525`.
125
126   asynchronous iterable
127      An object, that can be used in an :keyword:`async for` statement.
128      Must return an :term:`asynchronous iterator` from its
129      :meth:`__aiter__` method.  Introduced by :pep:`492`.
130
131   asynchronous iterator
132      An object that implements the :meth:`__aiter__` and :meth:`__anext__`
133      methods.  ``__anext__`` must return an :term:`awaitable` object.
134      :keyword:`async for` resolves the awaitables returned by an asynchronous
135      iterator's :meth:`__anext__` method until it raises a
136      :exc:`StopAsyncIteration` exception.  Introduced by :pep:`492`.
137
138   attribute
139      A value associated with an object which is usually referenced by name
140      using dotted expressions.
141      For example, if an object *o* has an attribute
142      *a* it would be referenced as *o.a*.
143
144      It is possible to give an object an attribute whose name is not an
145      identifier as defined by :ref:`identifiers`, for example using
146      :func:`setattr`, if the object allows it.
147      Such an attribute will not be accessible using a dotted expression,
148      and would instead need to be retrieved with :func:`getattr`.
149
150   awaitable
151      An object that can be used in an :keyword:`await` expression.  Can be
152      a :term:`coroutine` or an object with an :meth:`__await__` method.
153      See also :pep:`492`.
154
155   BDFL
156      Benevolent Dictator For Life, a.k.a. `Guido van Rossum
157      <https://gvanrossum.github.io/>`_, Python's creator.
158
159   binary file
160      A :term:`file object` able to read and write
161      :term:`bytes-like objects <bytes-like object>`.
162      Examples of binary files are files opened in binary mode (``'rb'``,
163      ``'wb'`` or ``'rb+'``), :data:`sys.stdin.buffer`,
164      :data:`sys.stdout.buffer`, and instances of :class:`io.BytesIO` and
165      :class:`gzip.GzipFile`.
166
167      See also :term:`text file` for a file object able to read and write
168      :class:`str` objects.
169
170   borrowed reference
171      In Python's C API, a borrowed reference is a reference to an object.
172      It does not modify the object reference count. It becomes a dangling
173      pointer if the object is destroyed. For example, a garbage collection can
174      remove the last :term:`strong reference` to the object and so destroy it.
175
176      Calling :c:func:`Py_INCREF` on the :term:`borrowed reference` is
177      recommended to convert it to a :term:`strong reference` in-place, except
178      when the object cannot be destroyed before the last usage of the borrowed
179      reference. The :c:func:`Py_NewRef` function can be used to create a new
180      :term:`strong reference`.
181
182   bytes-like object
183      An object that supports the :ref:`bufferobjects` and can
184      export a C-:term:`contiguous` buffer. This includes all :class:`bytes`,
185      :class:`bytearray`, and :class:`array.array` objects, as well as many
186      common :class:`memoryview` objects.  Bytes-like objects can
187      be used for various operations that work with binary data; these include
188      compression, saving to a binary file, and sending over a socket.
189
190      Some operations need the binary data to be mutable.  The documentation
191      often refers to these as "read-write bytes-like objects".  Example
192      mutable buffer objects include :class:`bytearray` and a
193      :class:`memoryview` of a :class:`bytearray`.
194      Other operations require the binary data to be stored in
195      immutable objects ("read-only bytes-like objects"); examples
196      of these include :class:`bytes` and a :class:`memoryview`
197      of a :class:`bytes` object.
198
199   bytecode
200      Python source code is compiled into bytecode, the internal representation
201      of a Python program in the CPython interpreter.  The bytecode is also
202      cached in ``.pyc`` files so that executing the same file is
203      faster the second time (recompilation from source to bytecode can be
204      avoided).  This "intermediate language" is said to run on a
205      :term:`virtual machine` that executes the machine code corresponding to
206      each bytecode. Do note that bytecodes are not expected to work between
207      different Python virtual machines, nor to be stable between Python
208      releases.
209
210      A list of bytecode instructions can be found in the documentation for
211      :ref:`the dis module <bytecodes>`.
212
213   callable
214      A callable is an object that can be called, possibly with a set
215      of arguments (see :term:`argument`), with the following syntax::
216
217         callable(argument1, argument2, argumentN)
218
219      A :term:`function`, and by extension a :term:`method`, is a callable.
220      An instance of a class that implements the :meth:`~object.__call__`
221      method is also a callable.
222
223   callback
224      A subroutine function which is passed as an argument to be executed at
225      some point in the future.
226
227   class
228      A template for creating user-defined objects. Class definitions
229      normally contain method definitions which operate on instances of the
230      class.
231
232   class variable
233      A variable defined in a class and intended to be modified only at
234      class level (i.e., not in an instance of the class).
235
236   complex number
237      An extension of the familiar real number system in which all numbers are
238      expressed as a sum of a real part and an imaginary part.  Imaginary
239      numbers are real multiples of the imaginary unit (the square root of
240      ``-1``), often written ``i`` in mathematics or ``j`` in
241      engineering.  Python has built-in support for complex numbers, which are
242      written with this latter notation; the imaginary part is written with a
243      ``j`` suffix, e.g., ``3+1j``.  To get access to complex equivalents of the
244      :mod:`math` module, use :mod:`cmath`.  Use of complex numbers is a fairly
245      advanced mathematical feature.  If you're not aware of a need for them,
246      it's almost certain you can safely ignore them.
247
248   context manager
249      An object which controls the environment seen in a :keyword:`with`
250      statement by defining :meth:`__enter__` and :meth:`__exit__` methods.
251      See :pep:`343`.
252
253   context variable
254      A variable which can have different values depending on its context.
255      This is similar to Thread-Local Storage in which each execution
256      thread may have a different value for a variable. However, with context
257      variables, there may be several contexts in one execution thread and the
258      main usage for context variables is to keep track of variables in
259      concurrent asynchronous tasks.
260      See :mod:`contextvars`.
261
262   contiguous
263      .. index:: C-contiguous, Fortran contiguous
264
265      A buffer is considered contiguous exactly if it is either
266      *C-contiguous* or *Fortran contiguous*.  Zero-dimensional buffers are
267      C and Fortran contiguous.  In one-dimensional arrays, the items
268      must be laid out in memory next to each other, in order of
269      increasing indexes starting from zero.  In multidimensional
270      C-contiguous arrays, the last index varies the fastest when
271      visiting items in order of memory address.  However, in
272      Fortran contiguous arrays, the first index varies the fastest.
273
274   coroutine
275      Coroutines are a more generalized form of subroutines. Subroutines are
276      entered at one point and exited at another point.  Coroutines can be
277      entered, exited, and resumed at many different points.  They can be
278      implemented with the :keyword:`async def` statement.  See also
279      :pep:`492`.
280
281   coroutine function
282      A function which returns a :term:`coroutine` object.  A coroutine
283      function may be defined with the :keyword:`async def` statement,
284      and may contain :keyword:`await`, :keyword:`async for`, and
285      :keyword:`async with` keywords.  These were introduced
286      by :pep:`492`.
287
288   CPython
289      The canonical implementation of the Python programming language, as
290      distributed on `python.org <https://www.python.org>`_.  The term "CPython"
291      is used when necessary to distinguish this implementation from others
292      such as Jython or IronPython.
293
294   decorator
295      A function returning another function, usually applied as a function
296      transformation using the ``@wrapper`` syntax.  Common examples for
297      decorators are :func:`classmethod` and :func:`staticmethod`.
298
299      The decorator syntax is merely syntactic sugar, the following two
300      function definitions are semantically equivalent::
301
302         def f(arg):
303             ...
304         f = staticmethod(f)
305
306         @staticmethod
307         def f(arg):
308             ...
309
310      The same concept exists for classes, but is less commonly used there.  See
311      the documentation for :ref:`function definitions <function>` and
312      :ref:`class definitions <class>` for more about decorators.
313
314   descriptor
315      Any object which defines the methods :meth:`__get__`, :meth:`__set__`, or
316      :meth:`__delete__`.  When a class attribute is a descriptor, its special
317      binding behavior is triggered upon attribute lookup.  Normally, using
318      *a.b* to get, set or delete an attribute looks up the object named *b* in
319      the class dictionary for *a*, but if *b* is a descriptor, the respective
320      descriptor method gets called.  Understanding descriptors is a key to a
321      deep understanding of Python because they are the basis for many features
322      including functions, methods, properties, class methods, static methods,
323      and reference to super classes.
324
325      For more information about descriptors' methods, see :ref:`descriptors`
326      or the :ref:`Descriptor How To Guide <descriptorhowto>`.
327
328   dictionary
329      An associative array, where arbitrary keys are mapped to values.  The
330      keys can be any object with :meth:`__hash__` and :meth:`__eq__` methods.
331      Called a hash in Perl.
332
333   dictionary comprehension
334      A compact way to process all or part of the elements in an iterable and
335      return a dictionary with the results. ``results = {n: n ** 2 for n in
336      range(10)}`` generates a dictionary containing key ``n`` mapped to
337      value ``n ** 2``. See :ref:`comprehensions`.
338
339   dictionary view
340      The objects returned from :meth:`dict.keys`, :meth:`dict.values`, and
341      :meth:`dict.items` are called dictionary views. They provide a dynamic
342      view on the dictionary’s entries, which means that when the dictionary
343      changes, the view reflects these changes. To force the
344      dictionary view to become a full list use ``list(dictview)``.  See
345      :ref:`dict-views`.
346
347   docstring
348      A string literal which appears as the first expression in a class,
349      function or module.  While ignored when the suite is executed, it is
350      recognized by the compiler and put into the :attr:`__doc__` attribute
351      of the enclosing class, function or module.  Since it is available via
352      introspection, it is the canonical place for documentation of the
353      object.
354
355   duck-typing
356      A programming style which does not look at an object's type to determine
357      if it has the right interface; instead, the method or attribute is simply
358      called or used ("If it looks like a duck and quacks like a duck, it
359      must be a duck.")  By emphasizing interfaces rather than specific types,
360      well-designed code improves its flexibility by allowing polymorphic
361      substitution.  Duck-typing avoids tests using :func:`type` or
362      :func:`isinstance`.  (Note, however, that duck-typing can be complemented
363      with :term:`abstract base classes <abstract base class>`.)  Instead, it
364      typically employs :func:`hasattr` tests or :term:`EAFP` programming.
365
366   EAFP
367      Easier to ask for forgiveness than permission.  This common Python coding
368      style assumes the existence of valid keys or attributes and catches
369      exceptions if the assumption proves false.  This clean and fast style is
370      characterized by the presence of many :keyword:`try` and :keyword:`except`
371      statements.  The technique contrasts with the :term:`LBYL` style
372      common to many other languages such as C.
373
374   expression
375      A piece of syntax which can be evaluated to some value.  In other words,
376      an expression is an accumulation of expression elements like literals,
377      names, attribute access, operators or function calls which all return a
378      value.  In contrast to many other languages, not all language constructs
379      are expressions.  There are also :term:`statement`\s which cannot be used
380      as expressions, such as :keyword:`while`.  Assignments are also statements,
381      not expressions.
382
383   extension module
384      A module written in C or C++, using Python's C API to interact with the
385      core and with user code.
386
387   f-string
388      String literals prefixed with ``'f'`` or ``'F'`` are commonly called
389      "f-strings" which is short for
390      :ref:`formatted string literals <f-strings>`.  See also :pep:`498`.
391
392   file object
393      An object exposing a file-oriented API (with methods such as
394      :meth:`read()` or :meth:`write()`) to an underlying resource.  Depending
395      on the way it was created, a file object can mediate access to a real
396      on-disk file or to another type of storage or communication device
397      (for example standard input/output, in-memory buffers, sockets, pipes,
398      etc.).  File objects are also called :dfn:`file-like objects` or
399      :dfn:`streams`.
400
401      There are actually three categories of file objects: raw
402      :term:`binary files <binary file>`, buffered
403      :term:`binary files <binary file>` and :term:`text files <text file>`.
404      Their interfaces are defined in the :mod:`io` module.  The canonical
405      way to create a file object is by using the :func:`open` function.
406
407   file-like object
408      A synonym for :term:`file object`.
409
410   filesystem encoding and error handler
411      Encoding and error handler used by Python to decode bytes from the
412      operating system and encode Unicode to the operating system.
413
414      The filesystem encoding must guarantee to successfully decode all bytes
415      below 128. If the file system encoding fails to provide this guarantee,
416      API functions can raise :exc:`UnicodeError`.
417
418      The :func:`sys.getfilesystemencoding` and
419      :func:`sys.getfilesystemencodeerrors` functions can be used to get the
420      filesystem encoding and error handler.
421
422      The :term:`filesystem encoding and error handler` are configured at
423      Python startup by the :c:func:`PyConfig_Read` function: see
424      :c:member:`~PyConfig.filesystem_encoding` and
425      :c:member:`~PyConfig.filesystem_errors` members of :c:type:`PyConfig`.
426
427      See also the :term:`locale encoding`.
428
429   finder
430      An object that tries to find the :term:`loader` for a module that is
431      being imported.
432
433      Since Python 3.3, there are two types of finder: :term:`meta path finders
434      <meta path finder>` for use with :data:`sys.meta_path`, and :term:`path
435      entry finders <path entry finder>` for use with :data:`sys.path_hooks`.
436
437      See :pep:`302`, :pep:`420` and :pep:`451` for much more detail.
438
439   floor division
440      Mathematical division that rounds down to nearest integer.  The floor
441      division operator is ``//``.  For example, the expression ``11 // 4``
442      evaluates to ``2`` in contrast to the ``2.75`` returned by float true
443      division.  Note that ``(-11) // 4`` is ``-3`` because that is ``-2.75``
444      rounded *downward*. See :pep:`238`.
445
446   function
447      A series of statements which returns some value to a caller. It can also
448      be passed zero or more :term:`arguments <argument>` which may be used in
449      the execution of the body. See also :term:`parameter`, :term:`method`,
450      and the :ref:`function` section.
451
452   function annotation
453      An :term:`annotation` of a function parameter or return value.
454
455      Function annotations are usually used for
456      :term:`type hints <type hint>`: for example, this function is expected to take two
457      :class:`int` arguments and is also expected to have an :class:`int`
458      return value::
459
460         def sum_two_numbers(a: int, b: int) -> int:
461            return a + b
462
463      Function annotation syntax is explained in section :ref:`function`.
464
465      See :term:`variable annotation` and :pep:`484`,
466      which describe this functionality.
467      Also see :ref:`annotations-howto`
468      for best practices on working with annotations.
469
470   __future__
471      A :ref:`future statement <future>`, ``from __future__ import <feature>``,
472      directs the compiler to compile the current module using syntax or
473      semantics that will become standard in a future release of Python.
474      The :mod:`__future__` module documents the possible values of
475      *feature*.  By importing this module and evaluating its variables,
476      you can see when a new feature was first added to the language and
477      when it will (or did) become the default::
478
479         >>> import __future__
480         >>> __future__.division
481         _Feature((2, 2, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 8192)
482
483   garbage collection
484      The process of freeing memory when it is not used anymore.  Python
485      performs garbage collection via reference counting and a cyclic garbage
486      collector that is able to detect and break reference cycles.  The
487      garbage collector can be controlled using the :mod:`gc` module.
488
489      .. index:: single: generator
490
491   generator
492      A function which returns a :term:`generator iterator`.  It looks like a
493      normal function except that it contains :keyword:`yield` expressions
494      for producing a series of values usable in a for-loop or that can be
495      retrieved one at a time with the :func:`next` function.
496
497      Usually refers to a generator function, but may refer to a
498      *generator iterator* in some contexts.  In cases where the intended
499      meaning isn't clear, using the full terms avoids ambiguity.
500
501   generator iterator
502      An object created by a :term:`generator` function.
503
504      Each :keyword:`yield` temporarily suspends processing, remembering the
505      location execution state (including local variables and pending
506      try-statements).  When the *generator iterator* resumes, it picks up where
507      it left off (in contrast to functions which start fresh on every
508      invocation).
509
510      .. index:: single: generator expression
511
512   generator expression
513      An expression that returns an iterator.  It looks like a normal expression
514      followed by a :keyword:`!for` clause defining a loop variable, range,
515      and an optional :keyword:`!if` clause.  The combined expression
516      generates values for an enclosing function::
517
518         >>> sum(i*i for i in range(10))         # sum of squares 0, 1, 4, ... 81
519         285
520
521   generic function
522      A function composed of multiple functions implementing the same operation
523      for different types. Which implementation should be used during a call is
524      determined by the dispatch algorithm.
525
526      See also the :term:`single dispatch` glossary entry, the
527      :func:`functools.singledispatch` decorator, and :pep:`443`.
528
529   generic type
530      A :term:`type` that can be parameterized; typically a
531      :ref:`container class<sequence-types>` such as :class:`list` or
532      :class:`dict`. Used for :term:`type hints <type hint>` and
533      :term:`annotations <annotation>`.
534
535      For more details, see :ref:`generic alias types<types-genericalias>`,
536      :pep:`483`, :pep:`484`, :pep:`585`, and the :mod:`typing` module.
537
538   GIL
539      See :term:`global interpreter lock`.
540
541   global interpreter lock
542      The mechanism used by the :term:`CPython` interpreter to assure that
543      only one thread executes Python :term:`bytecode` at a time.
544      This simplifies the CPython implementation by making the object model
545      (including critical built-in types such as :class:`dict`) implicitly
546      safe against concurrent access.  Locking the entire interpreter
547      makes it easier for the interpreter to be multi-threaded, at the
548      expense of much of the parallelism afforded by multi-processor
549      machines.
550
551      However, some extension modules, either standard or third-party,
552      are designed so as to release the GIL when doing computationally intensive
553      tasks such as compression or hashing.  Also, the GIL is always released
554      when doing I/O.
555
556      Past efforts to create a "free-threaded" interpreter (one which locks
557      shared data at a much finer granularity) have not been successful
558      because performance suffered in the common single-processor case. It
559      is believed that overcoming this performance issue would make the
560      implementation much more complicated and therefore costlier to maintain.
561
562
563   hash-based pyc
564      A bytecode cache file that uses the hash rather than the last-modified
565      time of the corresponding source file to determine its validity. See
566      :ref:`pyc-invalidation`.
567
568   hashable
569      An object is *hashable* if it has a hash value which never changes during
570      its lifetime (it needs a :meth:`__hash__` method), and can be compared to
571      other objects (it needs an :meth:`__eq__` method).  Hashable objects which
572      compare equal must have the same hash value.
573
574      Hashability makes an object usable as a dictionary key and a set member,
575      because these data structures use the hash value internally.
576
577      Most of Python's immutable built-in objects are hashable; mutable
578      containers (such as lists or dictionaries) are not; immutable
579      containers (such as tuples and frozensets) are only hashable if
580      their elements are hashable.  Objects which are
581      instances of user-defined classes are hashable by default.  They all
582      compare unequal (except with themselves), and their hash value is derived
583      from their :func:`id`.
584
585   IDLE
586      An Integrated Development and Learning Environment for Python.
587      :ref:`idle` is a basic editor and interpreter environment
588      which ships with the standard distribution of Python.
589
590   immutable
591      An object with a fixed value.  Immutable objects include numbers, strings and
592      tuples.  Such an object cannot be altered.  A new object has to
593      be created if a different value has to be stored.  They play an important
594      role in places where a constant hash value is needed, for example as a key
595      in a dictionary.
596
597   import path
598      A list of locations (or :term:`path entries <path entry>`) that are
599      searched by the :term:`path based finder` for modules to import. During
600      import, this list of locations usually comes from :data:`sys.path`, but
601      for subpackages it may also come from the parent package's ``__path__``
602      attribute.
603
604   importing
605      The process by which Python code in one module is made available to
606      Python code in another module.
607
608   importer
609      An object that both finds and loads a module; both a
610      :term:`finder` and :term:`loader` object.
611
612   interactive
613      Python has an interactive interpreter which means you can enter
614      statements and expressions at the interpreter prompt, immediately
615      execute them and see their results.  Just launch ``python`` with no
616      arguments (possibly by selecting it from your computer's main
617      menu). It is a very powerful way to test out new ideas or inspect
618      modules and packages (remember ``help(x)``).
619
620   interpreted
621      Python is an interpreted language, as opposed to a compiled one,
622      though the distinction can be blurry because of the presence of the
623      bytecode compiler.  This means that source files can be run directly
624      without explicitly creating an executable which is then run.
625      Interpreted languages typically have a shorter development/debug cycle
626      than compiled ones, though their programs generally also run more
627      slowly.  See also :term:`interactive`.
628
629   interpreter shutdown
630      When asked to shut down, the Python interpreter enters a special phase
631      where it gradually releases all allocated resources, such as modules
632      and various critical internal structures.  It also makes several calls
633      to the :term:`garbage collector <garbage collection>`. This can trigger
634      the execution of code in user-defined destructors or weakref callbacks.
635      Code executed during the shutdown phase can encounter various
636      exceptions as the resources it relies on may not function anymore
637      (common examples are library modules or the warnings machinery).
638
639      The main reason for interpreter shutdown is that the ``__main__`` module
640      or the script being run has finished executing.
641
642   iterable
643      An object capable of returning its members one at a time. Examples of
644      iterables include all sequence types (such as :class:`list`, :class:`str`,
645      and :class:`tuple`) and some non-sequence types like :class:`dict`,
646      :term:`file objects <file object>`, and objects of any classes you define
647      with an :meth:`__iter__` method or with a :meth:`__getitem__` method
648      that implements :term:`sequence` semantics.
649
650      Iterables can be
651      used in a :keyword:`for` loop and in many other places where a sequence is
652      needed (:func:`zip`, :func:`map`, ...).  When an iterable object is passed
653      as an argument to the built-in function :func:`iter`, it returns an
654      iterator for the object.  This iterator is good for one pass over the set
655      of values.  When using iterables, it is usually not necessary to call
656      :func:`iter` or deal with iterator objects yourself.  The ``for``
657      statement does that automatically for you, creating a temporary unnamed
658      variable to hold the iterator for the duration of the loop.  See also
659      :term:`iterator`, :term:`sequence`, and :term:`generator`.
660
661   iterator
662      An object representing a stream of data.  Repeated calls to the iterator's
663      :meth:`~iterator.__next__` method (or passing it to the built-in function
664      :func:`next`) return successive items in the stream.  When no more data
665      are available a :exc:`StopIteration` exception is raised instead.  At this
666      point, the iterator object is exhausted and any further calls to its
667      :meth:`__next__` method just raise :exc:`StopIteration` again.  Iterators
668      are required to have an :meth:`__iter__` method that returns the iterator
669      object itself so every iterator is also iterable and may be used in most
670      places where other iterables are accepted.  One notable exception is code
671      which attempts multiple iteration passes.  A container object (such as a
672      :class:`list`) produces a fresh new iterator each time you pass it to the
673      :func:`iter` function or use it in a :keyword:`for` loop.  Attempting this
674      with an iterator will just return the same exhausted iterator object used
675      in the previous iteration pass, making it appear like an empty container.
676
677      More information can be found in :ref:`typeiter`.
678
679      .. impl-detail::
680
681         CPython does not consistently apply the requirement that an iterator
682         define :meth:`__iter__`.
683
684   key function
685      A key function or collation function is a callable that returns a value
686      used for sorting or ordering.  For example, :func:`locale.strxfrm` is
687      used to produce a sort key that is aware of locale specific sort
688      conventions.
689
690      A number of tools in Python accept key functions to control how elements
691      are ordered or grouped.  They include :func:`min`, :func:`max`,
692      :func:`sorted`, :meth:`list.sort`, :func:`heapq.merge`,
693      :func:`heapq.nsmallest`, :func:`heapq.nlargest`, and
694      :func:`itertools.groupby`.
695
696      There are several ways to create a key function.  For example. the
697      :meth:`str.lower` method can serve as a key function for case insensitive
698      sorts.  Alternatively, a key function can be built from a
699      :keyword:`lambda` expression such as ``lambda r: (r[0], r[2])``.  Also,
700      :func:`operator.attrgetter`, :func:`operator.itemgetter`, and
701      :func:`operator.methodcaller` are three key function constructors.  See the :ref:`Sorting HOW TO
702      <sortinghowto>` for examples of how to create and use key functions.
703
704   keyword argument
705      See :term:`argument`.
706
707   lambda
708      An anonymous inline function consisting of a single :term:`expression`
709      which is evaluated when the function is called.  The syntax to create
710      a lambda function is ``lambda [parameters]: expression``
711
712   LBYL
713      Look before you leap.  This coding style explicitly tests for
714      pre-conditions before making calls or lookups.  This style contrasts with
715      the :term:`EAFP` approach and is characterized by the presence of many
716      :keyword:`if` statements.
717
718      In a multi-threaded environment, the LBYL approach can risk introducing a
719      race condition between "the looking" and "the leaping".  For example, the
720      code, ``if key in mapping: return mapping[key]`` can fail if another
721      thread removes *key* from *mapping* after the test, but before the lookup.
722      This issue can be solved with locks or by using the EAFP approach.
723
724   locale encoding
725      On Unix, it is the encoding of the LC_CTYPE locale. It can be set with
726      :func:`locale.setlocale(locale.LC_CTYPE, new_locale) <locale.setlocale>`.
727
728      On Windows, it is the ANSI code page (ex: ``"cp1252"``).
729
730      On Android and VxWorks, Python uses ``"utf-8"`` as the locale encoding.
731
732      ``locale.getencoding()`` can be used to get the locale encoding.
733
734      See also the :term:`filesystem encoding and error handler`.
735
736   list
737      A built-in Python :term:`sequence`.  Despite its name it is more akin
738      to an array in other languages than to a linked list since access to
739      elements is O(1).
740
741   list comprehension
742      A compact way to process all or part of the elements in a sequence and
743      return a list with the results.  ``result = ['{:#04x}'.format(x) for x in
744      range(256) if x % 2 == 0]`` generates a list of strings containing
745      even hex numbers (0x..) in the range from 0 to 255. The :keyword:`if`
746      clause is optional.  If omitted, all elements in ``range(256)`` are
747      processed.
748
749   loader
750      An object that loads a module. It must define a method named
751      :meth:`load_module`. A loader is typically returned by a
752      :term:`finder`. See :pep:`302` for details and
753      :class:`importlib.abc.Loader` for an :term:`abstract base class`.
754
755   magic method
756      .. index:: pair: magic; method
757
758      An informal synonym for :term:`special method`.
759
760   mapping
761      A container object that supports arbitrary key lookups and implements the
762      methods specified in the :class:`collections.abc.Mapping` or
763      :class:`collections.abc.MutableMapping`
764      :ref:`abstract base classes <collections-abstract-base-classes>`.  Examples
765      include :class:`dict`, :class:`collections.defaultdict`,
766      :class:`collections.OrderedDict` and :class:`collections.Counter`.
767
768   meta path finder
769      A :term:`finder` returned by a search of :data:`sys.meta_path`.  Meta path
770      finders are related to, but different from :term:`path entry finders
771      <path entry finder>`.
772
773      See :class:`importlib.abc.MetaPathFinder` for the methods that meta path
774      finders implement.
775
776   metaclass
777      The class of a class.  Class definitions create a class name, a class
778      dictionary, and a list of base classes.  The metaclass is responsible for
779      taking those three arguments and creating the class.  Most object oriented
780      programming languages provide a default implementation.  What makes Python
781      special is that it is possible to create custom metaclasses.  Most users
782      never need this tool, but when the need arises, metaclasses can provide
783      powerful, elegant solutions.  They have been used for logging attribute
784      access, adding thread-safety, tracking object creation, implementing
785      singletons, and many other tasks.
786
787      More information can be found in :ref:`metaclasses`.
788
789   method
790      A function which is defined inside a class body.  If called as an attribute
791      of an instance of that class, the method will get the instance object as
792      its first :term:`argument` (which is usually called ``self``).
793      See :term:`function` and :term:`nested scope`.
794
795   method resolution order
796      Method Resolution Order is the order in which base classes are searched
797      for a member during lookup. See `The Python 2.3 Method Resolution Order
798      <https://www.python.org/download/releases/2.3/mro/>`_ for details of the
799      algorithm used by the Python interpreter since the 2.3 release.
800
801   module
802      An object that serves as an organizational unit of Python code.  Modules
803      have a namespace containing arbitrary Python objects.  Modules are loaded
804      into Python by the process of :term:`importing`.
805
806      See also :term:`package`.
807
808   module spec
809      A namespace containing the import-related information used to load a
810      module. An instance of :class:`importlib.machinery.ModuleSpec`.
811
812   MRO
813      See :term:`method resolution order`.
814
815   mutable
816      Mutable objects can change their value but keep their :func:`id`.  See
817      also :term:`immutable`.
818
819   named tuple
820      The term "named tuple" applies to any type or class that inherits from
821      tuple and whose indexable elements are also accessible using named
822      attributes.  The type or class may have other features as well.
823
824      Several built-in types are named tuples, including the values returned
825      by :func:`time.localtime` and :func:`os.stat`.  Another example is
826      :data:`sys.float_info`::
827
828           >>> sys.float_info[1]                   # indexed access
829           1024
830           >>> sys.float_info.max_exp              # named field access
831           1024
832           >>> isinstance(sys.float_info, tuple)   # kind of tuple
833           True
834
835      Some named tuples are built-in types (such as the above examples).
836      Alternatively, a named tuple can be created from a regular class
837      definition that inherits from :class:`tuple` and that defines named
838      fields.  Such a class can be written by hand or it can be created with
839      the factory function :func:`collections.namedtuple`.  The latter
840      technique also adds some extra methods that may not be found in
841      hand-written or built-in named tuples.
842
843   namespace
844      The place where a variable is stored.  Namespaces are implemented as
845      dictionaries.  There are the local, global and built-in namespaces as well
846      as nested namespaces in objects (in methods).  Namespaces support
847      modularity by preventing naming conflicts.  For instance, the functions
848      :func:`builtins.open <.open>` and :func:`os.open` are distinguished by
849      their namespaces.  Namespaces also aid readability and maintainability by
850      making it clear which module implements a function.  For instance, writing
851      :func:`random.seed` or :func:`itertools.islice` makes it clear that those
852      functions are implemented by the :mod:`random` and :mod:`itertools`
853      modules, respectively.
854
855   namespace package
856      A :pep:`420` :term:`package` which serves only as a container for
857      subpackages.  Namespace packages may have no physical representation,
858      and specifically are not like a :term:`regular package` because they
859      have no ``__init__.py`` file.
860
861      See also :term:`module`.
862
863   nested scope
864      The ability to refer to a variable in an enclosing definition.  For
865      instance, a function defined inside another function can refer to
866      variables in the outer function.  Note that nested scopes by default work
867      only for reference and not for assignment.  Local variables both read and
868      write in the innermost scope.  Likewise, global variables read and write
869      to the global namespace.  The :keyword:`nonlocal` allows writing to outer
870      scopes.
871
872   new-style class
873      Old name for the flavor of classes now used for all class objects.  In
874      earlier Python versions, only new-style classes could use Python's newer,
875      versatile features like :attr:`~object.__slots__`, descriptors,
876      properties, :meth:`__getattribute__`, class methods, and static methods.
877
878   object
879      Any data with state (attributes or value) and defined behavior
880      (methods).  Also the ultimate base class of any :term:`new-style
881      class`.
882
883   package
884      A Python :term:`module` which can contain submodules or recursively,
885      subpackages.  Technically, a package is a Python module with a
886      ``__path__`` attribute.
887
888      See also :term:`regular package` and :term:`namespace package`.
889
890   parameter
891      A named entity in a :term:`function` (or method) definition that
892      specifies an :term:`argument` (or in some cases, arguments) that the
893      function can accept.  There are five kinds of parameter:
894
895      * :dfn:`positional-or-keyword`: specifies an argument that can be passed
896        either :term:`positionally <argument>` or as a :term:`keyword argument
897        <argument>`.  This is the default kind of parameter, for example *foo*
898        and *bar* in the following::
899
900           def func(foo, bar=None): ...
901
902      .. _positional-only_parameter:
903
904      * :dfn:`positional-only`: specifies an argument that can be supplied only
905        by position. Positional-only parameters can be defined by including a
906        ``/`` character in the parameter list of the function definition after
907        them, for example *posonly1* and *posonly2* in the following::
908
909           def func(posonly1, posonly2, /, positional_or_keyword): ...
910
911      .. _keyword-only_parameter:
912
913      * :dfn:`keyword-only`: specifies an argument that can be supplied only
914        by keyword.  Keyword-only parameters can be defined by including a
915        single var-positional parameter or bare ``*`` in the parameter list
916        of the function definition before them, for example *kw_only1* and
917        *kw_only2* in the following::
918
919           def func(arg, *, kw_only1, kw_only2): ...
920
921      * :dfn:`var-positional`: specifies that an arbitrary sequence of
922        positional arguments can be provided (in addition to any positional
923        arguments already accepted by other parameters).  Such a parameter can
924        be defined by prepending the parameter name with ``*``, for example
925        *args* in the following::
926
927           def func(*args, **kwargs): ...
928
929      * :dfn:`var-keyword`: specifies that arbitrarily many keyword arguments
930        can be provided (in addition to any keyword arguments already accepted
931        by other parameters).  Such a parameter can be defined by prepending
932        the parameter name with ``**``, for example *kwargs* in the example
933        above.
934
935      Parameters can specify both optional and required arguments, as well as
936      default values for some optional arguments.
937
938      See also the :term:`argument` glossary entry, the FAQ question on
939      :ref:`the difference between arguments and parameters
940      <faq-argument-vs-parameter>`, the :class:`inspect.Parameter` class, the
941      :ref:`function` section, and :pep:`362`.
942
943   path entry
944      A single location on the :term:`import path` which the :term:`path
945      based finder` consults to find modules for importing.
946
947   path entry finder
948      A :term:`finder` returned by a callable on :data:`sys.path_hooks`
949      (i.e. a :term:`path entry hook`) which knows how to locate modules given
950      a :term:`path entry`.
951
952      See :class:`importlib.abc.PathEntryFinder` for the methods that path entry
953      finders implement.
954
955   path entry hook
956      A callable on the :data:`sys.path_hook` list which returns a :term:`path
957      entry finder` if it knows how to find modules on a specific :term:`path
958      entry`.
959
960   path based finder
961      One of the default :term:`meta path finders <meta path finder>` which
962      searches an :term:`import path` for modules.
963
964   path-like object
965      An object representing a file system path. A path-like object is either
966      a :class:`str` or :class:`bytes` object representing a path, or an object
967      implementing the :class:`os.PathLike` protocol. An object that supports
968      the :class:`os.PathLike` protocol can be converted to a :class:`str` or
969      :class:`bytes` file system path by calling the :func:`os.fspath` function;
970      :func:`os.fsdecode` and :func:`os.fsencode` can be used to guarantee a
971      :class:`str` or :class:`bytes` result instead, respectively. Introduced
972      by :pep:`519`.
973
974   PEP
975      Python Enhancement Proposal. A PEP is a design document
976      providing information to the Python community, or describing a new
977      feature for Python or its processes or environment. PEPs should
978      provide a concise technical specification and a rationale for proposed
979      features.
980
981      PEPs are intended to be the primary mechanisms for proposing major new
982      features, for collecting community input on an issue, and for documenting
983      the design decisions that have gone into Python. The PEP author is
984      responsible for building consensus within the community and documenting
985      dissenting opinions.
986
987      See :pep:`1`.
988
989   portion
990      A set of files in a single directory (possibly stored in a zip file)
991      that contribute to a namespace package, as defined in :pep:`420`.
992
993   positional argument
994      See :term:`argument`.
995
996   provisional API
997      A provisional API is one which has been deliberately excluded from
998      the standard library's backwards compatibility guarantees.  While major
999      changes to such interfaces are not expected, as long as they are marked
1000      provisional, backwards incompatible changes (up to and including removal
1001      of the interface) may occur if deemed necessary by core developers.  Such
1002      changes will not be made gratuitously -- they will occur only if serious
1003      fundamental flaws are uncovered that were missed prior to the inclusion
1004      of the API.
1005
1006      Even for provisional APIs, backwards incompatible changes are seen as
1007      a "solution of last resort" - every attempt will still be made to find
1008      a backwards compatible resolution to any identified problems.
1009
1010      This process allows the standard library to continue to evolve over
1011      time, without locking in problematic design errors for extended periods
1012      of time.  See :pep:`411` for more details.
1013
1014   provisional package
1015      See :term:`provisional API`.
1016
1017   Python 3000
1018      Nickname for the Python 3.x release line (coined long ago when the
1019      release of version 3 was something in the distant future.)  This is also
1020      abbreviated "Py3k".
1021
1022   Pythonic
1023      An idea or piece of code which closely follows the most common idioms
1024      of the Python language, rather than implementing code using concepts
1025      common to other languages.  For example, a common idiom in Python is
1026      to loop over all elements of an iterable using a :keyword:`for`
1027      statement.  Many other languages don't have this type of construct, so
1028      people unfamiliar with Python sometimes use a numerical counter instead::
1029
1030          for i in range(len(food)):
1031              print(food[i])
1032
1033      As opposed to the cleaner, Pythonic method::
1034
1035         for piece in food:
1036             print(piece)
1037
1038   qualified name
1039      A dotted name showing the "path" from a module's global scope to a
1040      class, function or method defined in that module, as defined in
1041      :pep:`3155`.  For top-level functions and classes, the qualified name
1042      is the same as the object's name::
1043
1044         >>> class C:
1045         ...     class D:
1046         ...         def meth(self):
1047         ...             pass
1048         ...
1049         >>> C.__qualname__
1050         'C'
1051         >>> C.D.__qualname__
1052         'C.D'
1053         >>> C.D.meth.__qualname__
1054         'C.D.meth'
1055
1056      When used to refer to modules, the *fully qualified name* means the
1057      entire dotted path to the module, including any parent packages,
1058      e.g. ``email.mime.text``::
1059
1060         >>> import email.mime.text
1061         >>> email.mime.text.__name__
1062         'email.mime.text'
1063
1064   reference count
1065      The number of references to an object.  When the reference count of an
1066      object drops to zero, it is deallocated.  Reference counting is
1067      generally not visible to Python code, but it is a key element of the
1068      :term:`CPython` implementation.  Programmers can call the
1069      :func:`sys.getrefcount` function to return the
1070      reference count for a particular object.
1071
1072   regular package
1073      A traditional :term:`package`, such as a directory containing an
1074      ``__init__.py`` file.
1075
1076      See also :term:`namespace package`.
1077
1078   __slots__
1079      A declaration inside a class that saves memory by pre-declaring space for
1080      instance attributes and eliminating instance dictionaries.  Though
1081      popular, the technique is somewhat tricky to get right and is best
1082      reserved for rare cases where there are large numbers of instances in a
1083      memory-critical application.
1084
1085   sequence
1086      An :term:`iterable` which supports efficient element access using integer
1087      indices via the :meth:`__getitem__` special method and defines a
1088      :meth:`__len__` method that returns the length of the sequence.
1089      Some built-in sequence types are :class:`list`, :class:`str`,
1090      :class:`tuple`, and :class:`bytes`. Note that :class:`dict` also
1091      supports :meth:`__getitem__` and :meth:`__len__`, but is considered a
1092      mapping rather than a sequence because the lookups use arbitrary
1093      :term:`immutable` keys rather than integers.
1094
1095      The :class:`collections.abc.Sequence` abstract base class
1096      defines a much richer interface that goes beyond just
1097      :meth:`__getitem__` and :meth:`__len__`, adding :meth:`count`,
1098      :meth:`index`, :meth:`__contains__`, and
1099      :meth:`__reversed__`. Types that implement this expanded
1100      interface can be registered explicitly using
1101      :func:`~abc.ABCMeta.register`.
1102
1103   set comprehension
1104      A compact way to process all or part of the elements in an iterable and
1105      return a set with the results. ``results = {c for c in 'abracadabra' if
1106      c not in 'abc'}`` generates the set of strings ``{'r', 'd'}``.  See
1107      :ref:`comprehensions`.
1108
1109   single dispatch
1110      A form of :term:`generic function` dispatch where the implementation is
1111      chosen based on the type of a single argument.
1112
1113   slice
1114      An object usually containing a portion of a :term:`sequence`.  A slice is
1115      created using the subscript notation, ``[]`` with colons between numbers
1116      when several are given, such as in ``variable_name[1:3:5]``.  The bracket
1117      (subscript) notation uses :class:`slice` objects internally.
1118
1119   special method
1120      .. index:: pair: special; method
1121
1122      A method that is called implicitly by Python to execute a certain
1123      operation on a type, such as addition.  Such methods have names starting
1124      and ending with double underscores.  Special methods are documented in
1125      :ref:`specialnames`.
1126
1127   statement
1128      A statement is part of a suite (a "block" of code).  A statement is either
1129      an :term:`expression` or one of several constructs with a keyword, such
1130      as :keyword:`if`, :keyword:`while` or :keyword:`for`.
1131
1132   strong reference
1133      In Python's C API, a strong reference is a reference to an object
1134      which increments the object's reference count when it is created and
1135      decrements the object's reference count when it is deleted.
1136
1137      The :c:func:`Py_NewRef` function can be used to create a strong reference
1138      to an object. Usually, the :c:func:`Py_DECREF` function must be called on
1139      the strong reference before exiting the scope of the strong reference, to
1140      avoid leaking one reference.
1141
1142      See also :term:`borrowed reference`.
1143
1144   text encoding
1145      A string in Python is a sequence of Unicode code points (in range
1146      ``U+0000``--``U+10FFFF``). To store or transfer a string, it needs to be
1147      serialized as a sequence of bytes.
1148
1149      Serializing a string into a sequence of bytes is known as "encoding", and
1150      recreating the string from the sequence of bytes is known as "decoding".
1151
1152      There are a variety of different text serialization
1153      :ref:`codecs <standard-encodings>`, which are collectively referred to as
1154      "text encodings".
1155
1156   text file
1157      A :term:`file object` able to read and write :class:`str` objects.
1158      Often, a text file actually accesses a byte-oriented datastream
1159      and handles the :term:`text encoding` automatically.
1160      Examples of text files are files opened in text mode (``'r'`` or ``'w'``),
1161      :data:`sys.stdin`, :data:`sys.stdout`, and instances of
1162      :class:`io.StringIO`.
1163
1164      See also :term:`binary file` for a file object able to read and write
1165      :term:`bytes-like objects <bytes-like object>`.
1166
1167   triple-quoted string
1168      A string which is bound by three instances of either a quotation mark
1169      (") or an apostrophe (').  While they don't provide any functionality
1170      not available with single-quoted strings, they are useful for a number
1171      of reasons.  They allow you to include unescaped single and double
1172      quotes within a string and they can span multiple lines without the
1173      use of the continuation character, making them especially useful when
1174      writing docstrings.
1175
1176   type
1177      The type of a Python object determines what kind of object it is; every
1178      object has a type.  An object's type is accessible as its
1179      :attr:`~instance.__class__` attribute or can be retrieved with
1180      ``type(obj)``.
1181
1182   type alias
1183      A synonym for a type, created by assigning the type to an identifier.
1184
1185      Type aliases are useful for simplifying :term:`type hints <type hint>`.
1186      For example::
1187
1188         def remove_gray_shades(
1189                 colors: list[tuple[int, int, int]]) -> list[tuple[int, int, int]]:
1190             pass
1191
1192      could be made more readable like this::
1193
1194         Color = tuple[int, int, int]
1195
1196         def remove_gray_shades(colors: list[Color]) -> list[Color]:
1197             pass
1198
1199      See :mod:`typing` and :pep:`484`, which describe this functionality.
1200
1201   type hint
1202      An :term:`annotation` that specifies the expected type for a variable, a class
1203      attribute, or a function parameter or return value.
1204
1205      Type hints are optional and are not enforced by Python but
1206      they are useful to static type analysis tools, and aid IDEs with code
1207      completion and refactoring.
1208
1209      Type hints of global variables, class attributes, and functions,
1210      but not local variables, can be accessed using
1211      :func:`typing.get_type_hints`.
1212
1213      See :mod:`typing` and :pep:`484`, which describe this functionality.
1214
1215   universal newlines
1216      A manner of interpreting text streams in which all of the following are
1217      recognized as ending a line: the Unix end-of-line convention ``'\n'``,
1218      the Windows convention ``'\r\n'``, and the old Macintosh convention
1219      ``'\r'``.  See :pep:`278` and :pep:`3116`, as well as
1220      :func:`bytes.splitlines` for an additional use.
1221
1222   variable annotation
1223      An :term:`annotation` of a variable or a class attribute.
1224
1225      When annotating a variable or a class attribute, assignment is optional::
1226
1227         class C:
1228             field: 'annotation'
1229
1230      Variable annotations are usually used for
1231      :term:`type hints <type hint>`: for example this variable is expected to take
1232      :class:`int` values::
1233
1234         count: int = 0
1235
1236      Variable annotation syntax is explained in section :ref:`annassign`.
1237
1238      See :term:`function annotation`, :pep:`484`
1239      and :pep:`526`, which describe this functionality.
1240      Also see :ref:`annotations-howto`
1241      for best practices on working with annotations.
1242
1243   virtual environment
1244      A cooperatively isolated runtime environment that allows Python users
1245      and applications to install and upgrade Python distribution packages
1246      without interfering with the behaviour of other Python applications
1247      running on the same system.
1248
1249      See also :mod:`venv`.
1250
1251   virtual machine
1252      A computer defined entirely in software.  Python's virtual machine
1253      executes the :term:`bytecode` emitted by the bytecode compiler.
1254
1255   Zen of Python
1256      Listing of Python design principles and philosophies that are helpful in
1257      understanding and using the language.  The listing can be found by typing
1258      "``import this``" at the interactive prompt.
1259