• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1:tocdepth: 2
2
3===============
4Programming FAQ
5===============
6
7.. only:: html
8
9   .. contents::
10
11General Questions
12=================
13
14Is there a source code level debugger with breakpoints, single-stepping, etc.?
15------------------------------------------------------------------------------
16
17Yes.
18
19Several debuggers for Python are described below, and the built-in function
20:func:`breakpoint` allows you to drop into any of them.
21
22The pdb module is a simple but adequate console-mode debugger for Python. It is
23part of the standard Python library, and is :mod:`documented in the Library
24Reference Manual <pdb>`. You can also write your own debugger by using the code
25for pdb as an example.
26
27The IDLE interactive development environment, which is part of the standard
28Python distribution (normally available as Tools/scripts/idle), includes a
29graphical debugger.
30
31PythonWin is a Python IDE that includes a GUI debugger based on pdb.  The
32PythonWin debugger colors breakpoints and has quite a few cool features such as
33debugging non-PythonWin programs.  PythonWin is available as part of
34`pywin32 <https://github.com/mhammond/pywin32>`_ project and
35as a part of the
36`ActivePython <https://www.activestate.com/products/python/>`_ distribution.
37
38`Eric <http://eric-ide.python-projects.org/>`_ is an IDE built on PyQt
39and the Scintilla editing component.
40
41`trepan3k <https://github.com/rocky/python3-trepan/>`_ is a gdb-like debugger.
42
43`Visual Studio Code <https://code.visualstudio.com/>`_ is an IDE with debugging
44tools that integrates with version-control software.
45
46There are a number of commercial Python IDEs that include graphical debuggers.
47They include:
48
49* `Wing IDE <https://wingware.com/>`_
50* `Komodo IDE <https://www.activestate.com/products/komodo-ide/>`_
51* `PyCharm <https://www.jetbrains.com/pycharm/>`_
52
53
54Are there tools to help find bugs or perform static analysis?
55-------------------------------------------------------------
56
57Yes.
58
59`Pylint <https://www.pylint.org/>`_ and
60`Pyflakes <https://github.com/PyCQA/pyflakes>`_ do basic checking that will
61help you catch bugs sooner.
62
63Static type checkers such as `Mypy <http://mypy-lang.org/>`_,
64`Pyre <https://pyre-check.org/>`_, and
65`Pytype <https://github.com/google/pytype>`_ can check type hints in Python
66source code.
67
68
69.. _faq-create-standalone-binary:
70
71How can I create a stand-alone binary from a Python script?
72-----------------------------------------------------------
73
74You don't need the ability to compile Python to C code if all you want is a
75stand-alone program that users can download and run without having to install
76the Python distribution first.  There are a number of tools that determine the
77set of modules required by a program and bind these modules together with a
78Python binary to produce a single executable.
79
80One is to use the freeze tool, which is included in the Python source tree as
81``Tools/freeze``. It converts Python byte code to C arrays; a C compiler you can
82embed all your modules into a new program, which is then linked with the
83standard Python modules.
84
85It works by scanning your source recursively for import statements (in both
86forms) and looking for the modules in the standard Python path as well as in the
87source directory (for built-in modules).  It then turns the bytecode for modules
88written in Python into C code (array initializers that can be turned into code
89objects using the marshal module) and creates a custom-made config file that
90only contains those built-in modules which are actually used in the program.  It
91then compiles the generated C code and links it with the rest of the Python
92interpreter to form a self-contained binary which acts exactly like your script.
93
94The following packages can help with the creation of console and GUI
95executables:
96
97* `Nuitka <https://nuitka.net/>`_ (Cross-platform)
98* `PyInstaller <http://www.pyinstaller.org/>`_ (Cross-platform)
99* `PyOxidizer <https://pyoxidizer.readthedocs.io/en/stable/>`_ (Cross-platform)
100* `cx_Freeze <https://marcelotduarte.github.io/cx_Freeze/>`_ (Cross-platform)
101* `py2app <https://github.com/ronaldoussoren/py2app>`_ (macOS only)
102* `py2exe <http://www.py2exe.org/>`_ (Windows only)
103
104Are there coding standards or a style guide for Python programs?
105----------------------------------------------------------------
106
107Yes.  The coding style required for standard library modules is documented as
108:pep:`8`.
109
110
111Core Language
112=============
113
114Why am I getting an UnboundLocalError when the variable has a value?
115--------------------------------------------------------------------
116
117It can be a surprise to get the UnboundLocalError in previously working
118code when it is modified by adding an assignment statement somewhere in
119the body of a function.
120
121This code:
122
123   >>> x = 10
124   >>> def bar():
125   ...     print(x)
126   >>> bar()
127   10
128
129works, but this code:
130
131   >>> x = 10
132   >>> def foo():
133   ...     print(x)
134   ...     x += 1
135
136results in an UnboundLocalError:
137
138   >>> foo()
139   Traceback (most recent call last):
140     ...
141   UnboundLocalError: local variable 'x' referenced before assignment
142
143This is because when you make an assignment to a variable in a scope, that
144variable becomes local to that scope and shadows any similarly named variable
145in the outer scope.  Since the last statement in foo assigns a new value to
146``x``, the compiler recognizes it as a local variable.  Consequently when the
147earlier ``print(x)`` attempts to print the uninitialized local variable and
148an error results.
149
150In the example above you can access the outer scope variable by declaring it
151global:
152
153   >>> x = 10
154   >>> def foobar():
155   ...     global x
156   ...     print(x)
157   ...     x += 1
158   >>> foobar()
159   10
160
161This explicit declaration is required in order to remind you that (unlike the
162superficially analogous situation with class and instance variables) you are
163actually modifying the value of the variable in the outer scope:
164
165   >>> print(x)
166   11
167
168You can do a similar thing in a nested scope using the :keyword:`nonlocal`
169keyword:
170
171   >>> def foo():
172   ...    x = 10
173   ...    def bar():
174   ...        nonlocal x
175   ...        print(x)
176   ...        x += 1
177   ...    bar()
178   ...    print(x)
179   >>> foo()
180   10
181   11
182
183
184What are the rules for local and global variables in Python?
185------------------------------------------------------------
186
187In Python, variables that are only referenced inside a function are implicitly
188global.  If a variable is assigned a value anywhere within the function's body,
189it's assumed to be a local unless explicitly declared as global.
190
191Though a bit surprising at first, a moment's consideration explains this.  On
192one hand, requiring :keyword:`global` for assigned variables provides a bar
193against unintended side-effects.  On the other hand, if ``global`` was required
194for all global references, you'd be using ``global`` all the time.  You'd have
195to declare as global every reference to a built-in function or to a component of
196an imported module.  This clutter would defeat the usefulness of the ``global``
197declaration for identifying side-effects.
198
199
200Why do lambdas defined in a loop with different values all return the same result?
201----------------------------------------------------------------------------------
202
203Assume you use a for loop to define a few different lambdas (or even plain
204functions), e.g.::
205
206   >>> squares = []
207   >>> for x in range(5):
208   ...     squares.append(lambda: x**2)
209
210This gives you a list that contains 5 lambdas that calculate ``x**2``.  You
211might expect that, when called, they would return, respectively, ``0``, ``1``,
212``4``, ``9``, and ``16``.  However, when you actually try you will see that
213they all return ``16``::
214
215   >>> squares[2]()
216   16
217   >>> squares[4]()
218   16
219
220This happens because ``x`` is not local to the lambdas, but is defined in
221the outer scope, and it is accessed when the lambda is called --- not when it
222is defined.  At the end of the loop, the value of ``x`` is ``4``, so all the
223functions now return ``4**2``, i.e. ``16``.  You can also verify this by
224changing the value of ``x`` and see how the results of the lambdas change::
225
226   >>> x = 8
227   >>> squares[2]()
228   64
229
230In order to avoid this, you need to save the values in variables local to the
231lambdas, so that they don't rely on the value of the global ``x``::
232
233   >>> squares = []
234   >>> for x in range(5):
235   ...     squares.append(lambda n=x: n**2)
236
237Here, ``n=x`` creates a new variable ``n`` local to the lambda and computed
238when the lambda is defined so that it has the same value that ``x`` had at
239that point in the loop.  This means that the value of ``n`` will be ``0``
240in the first lambda, ``1`` in the second, ``2`` in the third, and so on.
241Therefore each lambda will now return the correct result::
242
243   >>> squares[2]()
244   4
245   >>> squares[4]()
246   16
247
248Note that this behaviour is not peculiar to lambdas, but applies to regular
249functions too.
250
251
252How do I share global variables across modules?
253------------------------------------------------
254
255The canonical way to share information across modules within a single program is
256to create a special module (often called config or cfg).  Just import the config
257module in all modules of your application; the module then becomes available as
258a global name.  Because there is only one instance of each module, any changes
259made to the module object get reflected everywhere.  For example:
260
261config.py::
262
263   x = 0   # Default value of the 'x' configuration setting
264
265mod.py::
266
267   import config
268   config.x = 1
269
270main.py::
271
272   import config
273   import mod
274   print(config.x)
275
276Note that using a module is also the basis for implementing the Singleton design
277pattern, for the same reason.
278
279
280What are the "best practices" for using import in a module?
281-----------------------------------------------------------
282
283In general, don't use ``from modulename import *``.  Doing so clutters the
284importer's namespace, and makes it much harder for linters to detect undefined
285names.
286
287Import modules at the top of a file.  Doing so makes it clear what other modules
288your code requires and avoids questions of whether the module name is in scope.
289Using one import per line makes it easy to add and delete module imports, but
290using multiple imports per line uses less screen space.
291
292It's good practice if you import modules in the following order:
293
2941. standard library modules -- e.g. ``sys``, ``os``, ``getopt``, ``re``
2952. third-party library modules (anything installed in Python's site-packages
296   directory) -- e.g. mx.DateTime, ZODB, PIL.Image, etc.
2973. locally-developed modules
298
299It is sometimes necessary to move imports to a function or class to avoid
300problems with circular imports.  Gordon McMillan says:
301
302   Circular imports are fine where both modules use the "import <module>" form
303   of import.  They fail when the 2nd module wants to grab a name out of the
304   first ("from module import name") and the import is at the top level.  That's
305   because names in the 1st are not yet available, because the first module is
306   busy importing the 2nd.
307
308In this case, if the second module is only used in one function, then the import
309can easily be moved into that function.  By the time the import is called, the
310first module will have finished initializing, and the second module can do its
311import.
312
313It may also be necessary to move imports out of the top level of code if some of
314the modules are platform-specific.  In that case, it may not even be possible to
315import all of the modules at the top of the file.  In this case, importing the
316correct modules in the corresponding platform-specific code is a good option.
317
318Only move imports into a local scope, such as inside a function definition, if
319it's necessary to solve a problem such as avoiding a circular import or are
320trying to reduce the initialization time of a module.  This technique is
321especially helpful if many of the imports are unnecessary depending on how the
322program executes.  You may also want to move imports into a function if the
323modules are only ever used in that function.  Note that loading a module the
324first time may be expensive because of the one time initialization of the
325module, but loading a module multiple times is virtually free, costing only a
326couple of dictionary lookups.  Even if the module name has gone out of scope,
327the module is probably available in :data:`sys.modules`.
328
329
330Why are default values shared between objects?
331----------------------------------------------
332
333This type of bug commonly bites neophyte programmers.  Consider this function::
334
335   def foo(mydict={}):  # Danger: shared reference to one dict for all calls
336       ... compute something ...
337       mydict[key] = value
338       return mydict
339
340The first time you call this function, ``mydict`` contains a single item.  The
341second time, ``mydict`` contains two items because when ``foo()`` begins
342executing, ``mydict`` starts out with an item already in it.
343
344It is often expected that a function call creates new objects for default
345values. This is not what happens. Default values are created exactly once, when
346the function is defined.  If that object is changed, like the dictionary in this
347example, subsequent calls to the function will refer to this changed object.
348
349By definition, immutable objects such as numbers, strings, tuples, and ``None``,
350are safe from change. Changes to mutable objects such as dictionaries, lists,
351and class instances can lead to confusion.
352
353Because of this feature, it is good programming practice to not use mutable
354objects as default values.  Instead, use ``None`` as the default value and
355inside the function, check if the parameter is ``None`` and create a new
356list/dictionary/whatever if it is.  For example, don't write::
357
358   def foo(mydict={}):
359       ...
360
361but::
362
363   def foo(mydict=None):
364       if mydict is None:
365           mydict = {}  # create a new dict for local namespace
366
367This feature can be useful.  When you have a function that's time-consuming to
368compute, a common technique is to cache the parameters and the resulting value
369of each call to the function, and return the cached value if the same value is
370requested again.  This is called "memoizing", and can be implemented like this::
371
372   # Callers can only provide two parameters and optionally pass _cache by keyword
373   def expensive(arg1, arg2, *, _cache={}):
374       if (arg1, arg2) in _cache:
375           return _cache[(arg1, arg2)]
376
377       # Calculate the value
378       result = ... expensive computation ...
379       _cache[(arg1, arg2)] = result           # Store result in the cache
380       return result
381
382You could use a global variable containing a dictionary instead of the default
383value; it's a matter of taste.
384
385
386How can I pass optional or keyword parameters from one function to another?
387---------------------------------------------------------------------------
388
389Collect the arguments using the ``*`` and ``**`` specifiers in the function's
390parameter list; this gives you the positional arguments as a tuple and the
391keyword arguments as a dictionary.  You can then pass these arguments when
392calling another function by using ``*`` and ``**``::
393
394   def f(x, *args, **kwargs):
395       ...
396       kwargs['width'] = '14.3c'
397       ...
398       g(x, *args, **kwargs)
399
400
401.. index::
402   single: argument; difference from parameter
403   single: parameter; difference from argument
404
405.. _faq-argument-vs-parameter:
406
407What is the difference between arguments and parameters?
408--------------------------------------------------------
409
410:term:`Parameters <parameter>` are defined by the names that appear in a
411function definition, whereas :term:`arguments <argument>` are the values
412actually passed to a function when calling it.  Parameters define what types of
413arguments a function can accept.  For example, given the function definition::
414
415   def func(foo, bar=None, **kwargs):
416       pass
417
418*foo*, *bar* and *kwargs* are parameters of ``func``.  However, when calling
419``func``, for example::
420
421   func(42, bar=314, extra=somevar)
422
423the values ``42``, ``314``, and ``somevar`` are arguments.
424
425
426Why did changing list 'y' also change list 'x'?
427------------------------------------------------
428
429If you wrote code like::
430
431   >>> x = []
432   >>> y = x
433   >>> y.append(10)
434   >>> y
435   [10]
436   >>> x
437   [10]
438
439you might be wondering why appending an element to ``y`` changed ``x`` too.
440
441There are two factors that produce this result:
442
4431) Variables are simply names that refer to objects.  Doing ``y = x`` doesn't
444   create a copy of the list -- it creates a new variable ``y`` that refers to
445   the same object ``x`` refers to.  This means that there is only one object
446   (the list), and both ``x`` and ``y`` refer to it.
4472) Lists are :term:`mutable`, which means that you can change their content.
448
449After the call to :meth:`~list.append`, the content of the mutable object has
450changed from ``[]`` to ``[10]``.  Since both the variables refer to the same
451object, using either name accesses the modified value ``[10]``.
452
453If we instead assign an immutable object to ``x``::
454
455   >>> x = 5  # ints are immutable
456   >>> y = x
457   >>> x = x + 1  # 5 can't be mutated, we are creating a new object here
458   >>> x
459   6
460   >>> y
461   5
462
463we can see that in this case ``x`` and ``y`` are not equal anymore.  This is
464because integers are :term:`immutable`, and when we do ``x = x + 1`` we are not
465mutating the int ``5`` by incrementing its value; instead, we are creating a
466new object (the int ``6``) and assigning it to ``x`` (that is, changing which
467object ``x`` refers to).  After this assignment we have two objects (the ints
468``6`` and ``5``) and two variables that refer to them (``x`` now refers to
469``6`` but ``y`` still refers to ``5``).
470
471Some operations (for example ``y.append(10)`` and ``y.sort()``) mutate the
472object, whereas superficially similar operations (for example ``y = y + [10]``
473and ``sorted(y)``) create a new object.  In general in Python (and in all cases
474in the standard library) a method that mutates an object will return ``None``
475to help avoid getting the two types of operations confused.  So if you
476mistakenly write ``y.sort()`` thinking it will give you a sorted copy of ``y``,
477you'll instead end up with ``None``, which will likely cause your program to
478generate an easily diagnosed error.
479
480However, there is one class of operations where the same operation sometimes
481has different behaviors with different types:  the augmented assignment
482operators.  For example, ``+=`` mutates lists but not tuples or ints (``a_list
483+= [1, 2, 3]`` is equivalent to ``a_list.extend([1, 2, 3])`` and mutates
484``a_list``, whereas ``some_tuple += (1, 2, 3)`` and ``some_int += 1`` create
485new objects).
486
487In other words:
488
489* If we have a mutable object (:class:`list`, :class:`dict`, :class:`set`,
490  etc.), we can use some specific operations to mutate it and all the variables
491  that refer to it will see the change.
492* If we have an immutable object (:class:`str`, :class:`int`, :class:`tuple`,
493  etc.), all the variables that refer to it will always see the same value,
494  but operations that transform that value into a new value always return a new
495  object.
496
497If you want to know if two variables refer to the same object or not, you can
498use the :keyword:`is` operator, or the built-in function :func:`id`.
499
500
501How do I write a function with output parameters (call by reference)?
502---------------------------------------------------------------------
503
504Remember that arguments are passed by assignment in Python.  Since assignment
505just creates references to objects, there's no alias between an argument name in
506the caller and callee, and so no call-by-reference per se.  You can achieve the
507desired effect in a number of ways.
508
5091) By returning a tuple of the results::
510
511      >>> def func1(a, b):
512      ...     a = 'new-value'        # a and b are local names
513      ...     b = b + 1              # assigned to new objects
514      ...     return a, b            # return new values
515      ...
516      >>> x, y = 'old-value', 99
517      >>> func1(x, y)
518      ('new-value', 100)
519
520   This is almost always the clearest solution.
521
5222) By using global variables.  This isn't thread-safe, and is not recommended.
523
5243) By passing a mutable (changeable in-place) object::
525
526      >>> def func2(a):
527      ...     a[0] = 'new-value'     # 'a' references a mutable list
528      ...     a[1] = a[1] + 1        # changes a shared object
529      ...
530      >>> args = ['old-value', 99]
531      >>> func2(args)
532      >>> args
533      ['new-value', 100]
534
5354) By passing in a dictionary that gets mutated::
536
537      >>> def func3(args):
538      ...     args['a'] = 'new-value'     # args is a mutable dictionary
539      ...     args['b'] = args['b'] + 1   # change it in-place
540      ...
541      >>> args = {'a': 'old-value', 'b': 99}
542      >>> func3(args)
543      >>> args
544      {'a': 'new-value', 'b': 100}
545
5465) Or bundle up values in a class instance::
547
548      >>> class Namespace:
549      ...     def __init__(self, /, **args):
550      ...         for key, value in args.items():
551      ...             setattr(self, key, value)
552      ...
553      >>> def func4(args):
554      ...     args.a = 'new-value'        # args is a mutable Namespace
555      ...     args.b = args.b + 1         # change object in-place
556      ...
557      >>> args = Namespace(a='old-value', b=99)
558      >>> func4(args)
559      >>> vars(args)
560      {'a': 'new-value', 'b': 100}
561
562
563   There's almost never a good reason to get this complicated.
564
565Your best choice is to return a tuple containing the multiple results.
566
567
568How do you make a higher order function in Python?
569--------------------------------------------------
570
571You have two choices: you can use nested scopes or you can use callable objects.
572For example, suppose you wanted to define ``linear(a,b)`` which returns a
573function ``f(x)`` that computes the value ``a*x+b``.  Using nested scopes::
574
575   def linear(a, b):
576       def result(x):
577           return a * x + b
578       return result
579
580Or using a callable object::
581
582   class linear:
583
584       def __init__(self, a, b):
585           self.a, self.b = a, b
586
587       def __call__(self, x):
588           return self.a * x + self.b
589
590In both cases, ::
591
592   taxes = linear(0.3, 2)
593
594gives a callable object where ``taxes(10e6) == 0.3 * 10e6 + 2``.
595
596The callable object approach has the disadvantage that it is a bit slower and
597results in slightly longer code.  However, note that a collection of callables
598can share their signature via inheritance::
599
600   class exponential(linear):
601       # __init__ inherited
602       def __call__(self, x):
603           return self.a * (x ** self.b)
604
605Object can encapsulate state for several methods::
606
607   class counter:
608
609       value = 0
610
611       def set(self, x):
612           self.value = x
613
614       def up(self):
615           self.value = self.value + 1
616
617       def down(self):
618           self.value = self.value - 1
619
620   count = counter()
621   inc, dec, reset = count.up, count.down, count.set
622
623Here ``inc()``, ``dec()`` and ``reset()`` act like functions which share the
624same counting variable.
625
626
627How do I copy an object in Python?
628----------------------------------
629
630In general, try :func:`copy.copy` or :func:`copy.deepcopy` for the general case.
631Not all objects can be copied, but most can.
632
633Some objects can be copied more easily.  Dictionaries have a :meth:`~dict.copy`
634method::
635
636   newdict = olddict.copy()
637
638Sequences can be copied by slicing::
639
640   new_l = l[:]
641
642
643How can I find the methods or attributes of an object?
644------------------------------------------------------
645
646For an instance x of a user-defined class, ``dir(x)`` returns an alphabetized
647list of the names containing the instance attributes and methods and attributes
648defined by its class.
649
650
651How can my code discover the name of an object?
652-----------------------------------------------
653
654Generally speaking, it can't, because objects don't really have names.
655Essentially, assignment always binds a name to a value; the same is true of
656``def`` and ``class`` statements, but in that case the value is a
657callable. Consider the following code::
658
659   >>> class A:
660   ...     pass
661   ...
662   >>> B = A
663   >>> a = B()
664   >>> b = a
665   >>> print(b)
666   <__main__.A object at 0x16D07CC>
667   >>> print(a)
668   <__main__.A object at 0x16D07CC>
669
670Arguably the class has a name: even though it is bound to two names and invoked
671through the name B the created instance is still reported as an instance of
672class A.  However, it is impossible to say whether the instance's name is a or
673b, since both names are bound to the same value.
674
675Generally speaking it should not be necessary for your code to "know the names"
676of particular values. Unless you are deliberately writing introspective
677programs, this is usually an indication that a change of approach might be
678beneficial.
679
680In comp.lang.python, Fredrik Lundh once gave an excellent analogy in answer to
681this question:
682
683   The same way as you get the name of that cat you found on your porch: the cat
684   (object) itself cannot tell you its name, and it doesn't really care -- so
685   the only way to find out what it's called is to ask all your neighbours
686   (namespaces) if it's their cat (object)...
687
688   ....and don't be surprised if you'll find that it's known by many names, or
689   no name at all!
690
691
692What's up with the comma operator's precedence?
693-----------------------------------------------
694
695Comma is not an operator in Python.  Consider this session::
696
697    >>> "a" in "b", "a"
698    (False, 'a')
699
700Since the comma is not an operator, but a separator between expressions the
701above is evaluated as if you had entered::
702
703    ("a" in "b"), "a"
704
705not::
706
707    "a" in ("b", "a")
708
709The same is true of the various assignment operators (``=``, ``+=`` etc).  They
710are not truly operators but syntactic delimiters in assignment statements.
711
712
713Is there an equivalent of C's "?:" ternary operator?
714----------------------------------------------------
715
716Yes, there is. The syntax is as follows::
717
718   [on_true] if [expression] else [on_false]
719
720   x, y = 50, 25
721   small = x if x < y else y
722
723Before this syntax was introduced in Python 2.5, a common idiom was to use
724logical operators::
725
726   [expression] and [on_true] or [on_false]
727
728However, this idiom is unsafe, as it can give wrong results when *on_true*
729has a false boolean value.  Therefore, it is always better to use
730the ``... if ... else ...`` form.
731
732
733Is it possible to write obfuscated one-liners in Python?
734--------------------------------------------------------
735
736Yes.  Usually this is done by nesting :keyword:`lambda` within
737:keyword:`!lambda`.  See the following three examples, due to Ulf Bartelt::
738
739   from functools import reduce
740
741   # Primes < 1000
742   print(list(filter(None,map(lambda y:y*reduce(lambda x,y:x*y!=0,
743   map(lambda x,y=y:y%x,range(2,int(pow(y,0.5)+1))),1),range(2,1000)))))
744
745   # First 10 Fibonacci numbers
746   print(list(map(lambda x,f=lambda x,f:(f(x-1,f)+f(x-2,f)) if x>1 else 1:
747   f(x,f), range(10))))
748
749   # Mandelbrot set
750   print((lambda Ru,Ro,Iu,Io,IM,Sx,Sy:reduce(lambda x,y:x+y,map(lambda y,
751   Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,Sy=Sy,L=lambda yc,Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,i=IM,
752   Sx=Sx,Sy=Sy:reduce(lambda x,y:x+y,map(lambda x,xc=Ru,yc=yc,Ru=Ru,Ro=Ro,
753   i=i,Sx=Sx,F=lambda xc,yc,x,y,k,f=lambda xc,yc,x,y,k,f:(k<=0)or (x*x+y*y
754   >=4.0) or 1+f(xc,yc,x*x-y*y+xc,2.0*x*y+yc,k-1,f):f(xc,yc,x,y,k,f):chr(
755   64+F(Ru+x*(Ro-Ru)/Sx,yc,0,0,i)),range(Sx))):L(Iu+y*(Io-Iu)/Sy),range(Sy
756   ))))(-2.1, 0.7, -1.2, 1.2, 30, 80, 24))
757   #    \___ ___/  \___ ___/  |   |   |__ lines on screen
758   #        V          V      |   |______ columns on screen
759   #        |          |      |__________ maximum of "iterations"
760   #        |          |_________________ range on y axis
761   #        |____________________________ range on x axis
762
763Don't try this at home, kids!
764
765
766.. _faq-positional-only-arguments:
767
768What does the slash(/) in the parameter list of a function mean?
769----------------------------------------------------------------
770
771A slash in the argument list of a function denotes that the parameters prior to
772it are positional-only.  Positional-only parameters are the ones without an
773externally-usable name.  Upon calling a function that accepts positional-only
774parameters, arguments are mapped to parameters based solely on their position.
775For example, :func:`divmod` is a function that accepts positional-only
776parameters. Its documentation looks like this::
777
778   >>> help(divmod)
779   Help on built-in function divmod in module builtins:
780
781   divmod(x, y, /)
782       Return the tuple (x//y, x%y).  Invariant: div*y + mod == x.
783
784The slash at the end of the parameter list means that both parameters are
785positional-only. Thus, calling :func:`divmod` with keyword arguments would lead
786to an error::
787
788   >>> divmod(x=3, y=4)
789   Traceback (most recent call last):
790     File "<stdin>", line 1, in <module>
791   TypeError: divmod() takes no keyword arguments
792
793
794Numbers and strings
795===================
796
797How do I specify hexadecimal and octal integers?
798------------------------------------------------
799
800To specify an octal digit, precede the octal value with a zero, and then a lower
801or uppercase "o".  For example, to set the variable "a" to the octal value "10"
802(8 in decimal), type::
803
804   >>> a = 0o10
805   >>> a
806   8
807
808Hexadecimal is just as easy.  Simply precede the hexadecimal number with a zero,
809and then a lower or uppercase "x".  Hexadecimal digits can be specified in lower
810or uppercase.  For example, in the Python interpreter::
811
812   >>> a = 0xa5
813   >>> a
814   165
815   >>> b = 0XB2
816   >>> b
817   178
818
819
820Why does -22 // 10 return -3?
821-----------------------------
822
823It's primarily driven by the desire that ``i % j`` have the same sign as ``j``.
824If you want that, and also want::
825
826    i == (i // j) * j + (i % j)
827
828then integer division has to return the floor.  C also requires that identity to
829hold, and then compilers that truncate ``i // j`` need to make ``i % j`` have
830the same sign as ``i``.
831
832There are few real use cases for ``i % j`` when ``j`` is negative.  When ``j``
833is positive, there are many, and in virtually all of them it's more useful for
834``i % j`` to be ``>= 0``.  If the clock says 10 now, what did it say 200 hours
835ago?  ``-190 % 12 == 2`` is useful; ``-190 % 12 == -10`` is a bug waiting to
836bite.
837
838
839How do I get int literal attribute instead of SyntaxError?
840----------------------------------------------------------
841
842Trying to lookup an ``int`` literal attribute in the normal manner gives
843a syntax error because the period is seen as a decimal point::
844
845   >>> 1.__class__
846     File "<stdin>", line 1
847     1.__class__
848      ^
849   SyntaxError: invalid decimal literal
850
851The solution is to separate the literal from the period
852with either a space or parentheses.
853
854   >>> 1 .__class__
855   <class 'int'>
856   >>> (1).__class__
857   <class 'int'>
858
859
860How do I convert a string to a number?
861--------------------------------------
862
863For integers, use the built-in :func:`int` type constructor, e.g. ``int('144')
864== 144``.  Similarly, :func:`float` converts to floating-point,
865e.g. ``float('144') == 144.0``.
866
867By default, these interpret the number as decimal, so that ``int('0144') ==
868144`` holds true, and ``int('0x144')`` raises :exc:`ValueError`. ``int(string,
869base)`` takes the base to convert from as a second optional argument, so ``int(
870'0x144', 16) == 324``.  If the base is specified as 0, the number is interpreted
871using Python's rules: a leading '0o' indicates octal, and '0x' indicates a hex
872number.
873
874Do not use the built-in function :func:`eval` if all you need is to convert
875strings to numbers.  :func:`eval` will be significantly slower and it presents a
876security risk: someone could pass you a Python expression that might have
877unwanted side effects.  For example, someone could pass
878``__import__('os').system("rm -rf $HOME")`` which would erase your home
879directory.
880
881:func:`eval` also has the effect of interpreting numbers as Python expressions,
882so that e.g. ``eval('09')`` gives a syntax error because Python does not allow
883leading '0' in a decimal number (except '0').
884
885
886How do I convert a number to a string?
887--------------------------------------
888
889To convert, e.g., the number 144 to the string '144', use the built-in type
890constructor :func:`str`.  If you want a hexadecimal or octal representation, use
891the built-in functions :func:`hex` or :func:`oct`.  For fancy formatting, see
892the :ref:`f-strings` and :ref:`formatstrings` sections,
893e.g. ``"{:04d}".format(144)`` yields
894``'0144'`` and ``"{:.3f}".format(1.0/3.0)`` yields ``'0.333'``.
895
896
897How do I modify a string in place?
898----------------------------------
899
900You can't, because strings are immutable.  In most situations, you should
901simply construct a new string from the various parts you want to assemble
902it from.  However, if you need an object with the ability to modify in-place
903unicode data, try using an :class:`io.StringIO` object or the :mod:`array`
904module::
905
906   >>> import io
907   >>> s = "Hello, world"
908   >>> sio = io.StringIO(s)
909   >>> sio.getvalue()
910   'Hello, world'
911   >>> sio.seek(7)
912   7
913   >>> sio.write("there!")
914   6
915   >>> sio.getvalue()
916   'Hello, there!'
917
918   >>> import array
919   >>> a = array.array('u', s)
920   >>> print(a)
921   array('u', 'Hello, world')
922   >>> a[0] = 'y'
923   >>> print(a)
924   array('u', 'yello, world')
925   >>> a.tounicode()
926   'yello, world'
927
928
929How do I use strings to call functions/methods?
930-----------------------------------------------
931
932There are various techniques.
933
934* The best is to use a dictionary that maps strings to functions.  The primary
935  advantage of this technique is that the strings do not need to match the names
936  of the functions.  This is also the primary technique used to emulate a case
937  construct::
938
939     def a():
940         pass
941
942     def b():
943         pass
944
945     dispatch = {'go': a, 'stop': b}  # Note lack of parens for funcs
946
947     dispatch[get_input()]()  # Note trailing parens to call function
948
949* Use the built-in function :func:`getattr`::
950
951     import foo
952     getattr(foo, 'bar')()
953
954  Note that :func:`getattr` works on any object, including classes, class
955  instances, modules, and so on.
956
957  This is used in several places in the standard library, like this::
958
959     class Foo:
960         def do_foo(self):
961             ...
962
963         def do_bar(self):
964             ...
965
966     f = getattr(foo_instance, 'do_' + opname)
967     f()
968
969
970* Use :func:`locals` to resolve the function name::
971
972     def myFunc():
973         print("hello")
974
975     fname = "myFunc"
976
977     f = locals()[fname]
978     f()
979
980
981Is there an equivalent to Perl's chomp() for removing trailing newlines from strings?
982-------------------------------------------------------------------------------------
983
984You can use ``S.rstrip("\r\n")`` to remove all occurrences of any line
985terminator from the end of the string ``S`` without removing other trailing
986whitespace.  If the string ``S`` represents more than one line, with several
987empty lines at the end, the line terminators for all the blank lines will
988be removed::
989
990   >>> lines = ("line 1 \r\n"
991   ...          "\r\n"
992   ...          "\r\n")
993   >>> lines.rstrip("\n\r")
994   'line 1 '
995
996Since this is typically only desired when reading text one line at a time, using
997``S.rstrip()`` this way works well.
998
999
1000Is there a scanf() or sscanf() equivalent?
1001------------------------------------------
1002
1003Not as such.
1004
1005For simple input parsing, the easiest approach is usually to split the line into
1006whitespace-delimited words using the :meth:`~str.split` method of string objects
1007and then convert decimal strings to numeric values using :func:`int` or
1008:func:`float`.  ``split()`` supports an optional "sep" parameter which is useful
1009if the line uses something other than whitespace as a separator.
1010
1011For more complicated input parsing, regular expressions are more powerful
1012than C's :c:func:`sscanf` and better suited for the task.
1013
1014
1015What does 'UnicodeDecodeError' or 'UnicodeEncodeError' error  mean?
1016-------------------------------------------------------------------
1017
1018See the :ref:`unicode-howto`.
1019
1020
1021Performance
1022===========
1023
1024My program is too slow. How do I speed it up?
1025---------------------------------------------
1026
1027That's a tough one, in general.  First, here are a list of things to
1028remember before diving further:
1029
1030* Performance characteristics vary across Python implementations.  This FAQ
1031  focuses on :term:`CPython`.
1032* Behaviour can vary across operating systems, especially when talking about
1033  I/O or multi-threading.
1034* You should always find the hot spots in your program *before* attempting to
1035  optimize any code (see the :mod:`profile` module).
1036* Writing benchmark scripts will allow you to iterate quickly when searching
1037  for improvements (see the :mod:`timeit` module).
1038* It is highly recommended to have good code coverage (through unit testing
1039  or any other technique) before potentially introducing regressions hidden
1040  in sophisticated optimizations.
1041
1042That being said, there are many tricks to speed up Python code.  Here are
1043some general principles which go a long way towards reaching acceptable
1044performance levels:
1045
1046* Making your algorithms faster (or changing to faster ones) can yield
1047  much larger benefits than trying to sprinkle micro-optimization tricks
1048  all over your code.
1049
1050* Use the right data structures.  Study documentation for the :ref:`bltin-types`
1051  and the :mod:`collections` module.
1052
1053* When the standard library provides a primitive for doing something, it is
1054  likely (although not guaranteed) to be faster than any alternative you
1055  may come up with.  This is doubly true for primitives written in C, such
1056  as builtins and some extension types.  For example, be sure to use
1057  either the :meth:`list.sort` built-in method or the related :func:`sorted`
1058  function to do sorting (and see the :ref:`sortinghowto` for examples
1059  of moderately advanced usage).
1060
1061* Abstractions tend to create indirections and force the interpreter to work
1062  more.  If the levels of indirection outweigh the amount of useful work
1063  done, your program will be slower.  You should avoid excessive abstraction,
1064  especially under the form of tiny functions or methods (which are also often
1065  detrimental to readability).
1066
1067If you have reached the limit of what pure Python can allow, there are tools
1068to take you further away.  For example, `Cython <http://cython.org>`_ can
1069compile a slightly modified version of Python code into a C extension, and
1070can be used on many different platforms.  Cython can take advantage of
1071compilation (and optional type annotations) to make your code significantly
1072faster than when interpreted.  If you are confident in your C programming
1073skills, you can also :ref:`write a C extension module <extending-index>`
1074yourself.
1075
1076.. seealso::
1077   The wiki page devoted to `performance tips
1078   <https://wiki.python.org/moin/PythonSpeed/PerformanceTips>`_.
1079
1080.. _efficient_string_concatenation:
1081
1082What is the most efficient way to concatenate many strings together?
1083--------------------------------------------------------------------
1084
1085:class:`str` and :class:`bytes` objects are immutable, therefore concatenating
1086many strings together is inefficient as each concatenation creates a new
1087object.  In the general case, the total runtime cost is quadratic in the
1088total string length.
1089
1090To accumulate many :class:`str` objects, the recommended idiom is to place
1091them into a list and call :meth:`str.join` at the end::
1092
1093   chunks = []
1094   for s in my_strings:
1095       chunks.append(s)
1096   result = ''.join(chunks)
1097
1098(another reasonably efficient idiom is to use :class:`io.StringIO`)
1099
1100To accumulate many :class:`bytes` objects, the recommended idiom is to extend
1101a :class:`bytearray` object using in-place concatenation (the ``+=`` operator)::
1102
1103   result = bytearray()
1104   for b in my_bytes_objects:
1105       result += b
1106
1107
1108Sequences (Tuples/Lists)
1109========================
1110
1111How do I convert between tuples and lists?
1112------------------------------------------
1113
1114The type constructor ``tuple(seq)`` converts any sequence (actually, any
1115iterable) into a tuple with the same items in the same order.
1116
1117For example, ``tuple([1, 2, 3])`` yields ``(1, 2, 3)`` and ``tuple('abc')``
1118yields ``('a', 'b', 'c')``.  If the argument is a tuple, it does not make a copy
1119but returns the same object, so it is cheap to call :func:`tuple` when you
1120aren't sure that an object is already a tuple.
1121
1122The type constructor ``list(seq)`` converts any sequence or iterable into a list
1123with the same items in the same order.  For example, ``list((1, 2, 3))`` yields
1124``[1, 2, 3]`` and ``list('abc')`` yields ``['a', 'b', 'c']``.  If the argument
1125is a list, it makes a copy just like ``seq[:]`` would.
1126
1127
1128What's a negative index?
1129------------------------
1130
1131Python sequences are indexed with positive numbers and negative numbers.  For
1132positive numbers 0 is the first index 1 is the second index and so forth.  For
1133negative indices -1 is the last index and -2 is the penultimate (next to last)
1134index and so forth.  Think of ``seq[-n]`` as the same as ``seq[len(seq)-n]``.
1135
1136Using negative indices can be very convenient.  For example ``S[:-1]`` is all of
1137the string except for its last character, which is useful for removing the
1138trailing newline from a string.
1139
1140
1141How do I iterate over a sequence in reverse order?
1142--------------------------------------------------
1143
1144Use the :func:`reversed` built-in function::
1145
1146   for x in reversed(sequence):
1147       ...  # do something with x ...
1148
1149This won't touch your original sequence, but build a new copy with reversed
1150order to iterate over.
1151
1152
1153How do you remove duplicates from a list?
1154-----------------------------------------
1155
1156See the Python Cookbook for a long discussion of many ways to do this:
1157
1158   https://code.activestate.com/recipes/52560/
1159
1160If you don't mind reordering the list, sort it and then scan from the end of the
1161list, deleting duplicates as you go::
1162
1163   if mylist:
1164       mylist.sort()
1165       last = mylist[-1]
1166       for i in range(len(mylist)-2, -1, -1):
1167           if last == mylist[i]:
1168               del mylist[i]
1169           else:
1170               last = mylist[i]
1171
1172If all elements of the list may be used as set keys (i.e. they are all
1173:term:`hashable`) this is often faster ::
1174
1175   mylist = list(set(mylist))
1176
1177This converts the list into a set, thereby removing duplicates, and then back
1178into a list.
1179
1180
1181How do you remove multiple items from a list
1182--------------------------------------------
1183
1184As with removing duplicates, explicitly iterating in reverse with a
1185delete condition is one possibility.  However, it is easier and faster
1186to use slice replacement with an implicit or explicit forward iteration.
1187Here are three variations.::
1188
1189   mylist[:] = filter(keep_function, mylist)
1190   mylist[:] = (x for x in mylist if keep_condition)
1191   mylist[:] = [x for x in mylist if keep_condition]
1192
1193The list comprehension may be fastest.
1194
1195
1196How do you make an array in Python?
1197-----------------------------------
1198
1199Use a list::
1200
1201   ["this", 1, "is", "an", "array"]
1202
1203Lists are equivalent to C or Pascal arrays in their time complexity; the primary
1204difference is that a Python list can contain objects of many different types.
1205
1206The ``array`` module also provides methods for creating arrays of fixed types
1207with compact representations, but they are slower to index than lists.  Also
1208note that NumPy and other third party packages define array-like structures with
1209various characteristics as well.
1210
1211To get Lisp-style linked lists, you can emulate cons cells using tuples::
1212
1213   lisp_list = ("like",  ("this",  ("example", None) ) )
1214
1215If mutability is desired, you could use lists instead of tuples.  Here the
1216analogue of lisp car is ``lisp_list[0]`` and the analogue of cdr is
1217``lisp_list[1]``.  Only do this if you're sure you really need to, because it's
1218usually a lot slower than using Python lists.
1219
1220
1221.. _faq-multidimensional-list:
1222
1223How do I create a multidimensional list?
1224----------------------------------------
1225
1226You probably tried to make a multidimensional array like this::
1227
1228   >>> A = [[None] * 2] * 3
1229
1230This looks correct if you print it:
1231
1232.. testsetup::
1233
1234   A = [[None] * 2] * 3
1235
1236.. doctest::
1237
1238   >>> A
1239   [[None, None], [None, None], [None, None]]
1240
1241But when you assign a value, it shows up in multiple places:
1242
1243.. testsetup::
1244
1245   A = [[None] * 2] * 3
1246
1247.. doctest::
1248
1249   >>> A[0][0] = 5
1250   >>> A
1251   [[5, None], [5, None], [5, None]]
1252
1253The reason is that replicating a list with ``*`` doesn't create copies, it only
1254creates references to the existing objects.  The ``*3`` creates a list
1255containing 3 references to the same list of length two.  Changes to one row will
1256show in all rows, which is almost certainly not what you want.
1257
1258The suggested approach is to create a list of the desired length first and then
1259fill in each element with a newly created list::
1260
1261   A = [None] * 3
1262   for i in range(3):
1263       A[i] = [None] * 2
1264
1265This generates a list containing 3 different lists of length two.  You can also
1266use a list comprehension::
1267
1268   w, h = 2, 3
1269   A = [[None] * w for i in range(h)]
1270
1271Or, you can use an extension that provides a matrix datatype; `NumPy
1272<http://www.numpy.org/>`_ is the best known.
1273
1274
1275How do I apply a method to a sequence of objects?
1276-------------------------------------------------
1277
1278Use a list comprehension::
1279
1280   result = [obj.method() for obj in mylist]
1281
1282.. _faq-augmented-assignment-tuple-error:
1283
1284Why does a_tuple[i] += ['item'] raise an exception when the addition works?
1285---------------------------------------------------------------------------
1286
1287This is because of a combination of the fact that augmented assignment
1288operators are *assignment* operators, and the difference between mutable and
1289immutable objects in Python.
1290
1291This discussion applies in general when augmented assignment operators are
1292applied to elements of a tuple that point to mutable objects, but we'll use
1293a ``list`` and ``+=`` as our exemplar.
1294
1295If you wrote::
1296
1297   >>> a_tuple = (1, 2)
1298   >>> a_tuple[0] += 1
1299   Traceback (most recent call last):
1300      ...
1301   TypeError: 'tuple' object does not support item assignment
1302
1303The reason for the exception should be immediately clear: ``1`` is added to the
1304object ``a_tuple[0]`` points to (``1``), producing the result object, ``2``,
1305but when we attempt to assign the result of the computation, ``2``, to element
1306``0`` of the tuple, we get an error because we can't change what an element of
1307a tuple points to.
1308
1309Under the covers, what this augmented assignment statement is doing is
1310approximately this::
1311
1312   >>> result = a_tuple[0] + 1
1313   >>> a_tuple[0] = result
1314   Traceback (most recent call last):
1315     ...
1316   TypeError: 'tuple' object does not support item assignment
1317
1318It is the assignment part of the operation that produces the error, since a
1319tuple is immutable.
1320
1321When you write something like::
1322
1323   >>> a_tuple = (['foo'], 'bar')
1324   >>> a_tuple[0] += ['item']
1325   Traceback (most recent call last):
1326     ...
1327   TypeError: 'tuple' object does not support item assignment
1328
1329The exception is a bit more surprising, and even more surprising is the fact
1330that even though there was an error, the append worked::
1331
1332    >>> a_tuple[0]
1333    ['foo', 'item']
1334
1335To see why this happens, you need to know that (a) if an object implements an
1336``__iadd__`` magic method, it gets called when the ``+=`` augmented assignment
1337is executed, and its return value is what gets used in the assignment statement;
1338and (b) for lists, ``__iadd__`` is equivalent to calling ``extend`` on the list
1339and returning the list.  That's why we say that for lists, ``+=`` is a
1340"shorthand" for ``list.extend``::
1341
1342    >>> a_list = []
1343    >>> a_list += [1]
1344    >>> a_list
1345    [1]
1346
1347This is equivalent to::
1348
1349    >>> result = a_list.__iadd__([1])
1350    >>> a_list = result
1351
1352The object pointed to by a_list has been mutated, and the pointer to the
1353mutated object is assigned back to ``a_list``.  The end result of the
1354assignment is a no-op, since it is a pointer to the same object that ``a_list``
1355was previously pointing to, but the assignment still happens.
1356
1357Thus, in our tuple example what is happening is equivalent to::
1358
1359   >>> result = a_tuple[0].__iadd__(['item'])
1360   >>> a_tuple[0] = result
1361   Traceback (most recent call last):
1362     ...
1363   TypeError: 'tuple' object does not support item assignment
1364
1365The ``__iadd__`` succeeds, and thus the list is extended, but even though
1366``result`` points to the same object that ``a_tuple[0]`` already points to,
1367that final assignment still results in an error, because tuples are immutable.
1368
1369
1370I want to do a complicated sort: can you do a Schwartzian Transform in Python?
1371------------------------------------------------------------------------------
1372
1373The technique, attributed to Randal Schwartz of the Perl community, sorts the
1374elements of a list by a metric which maps each element to its "sort value". In
1375Python, use the ``key`` argument for the :meth:`list.sort` method::
1376
1377   Isorted = L[:]
1378   Isorted.sort(key=lambda s: int(s[10:15]))
1379
1380
1381How can I sort one list by values from another list?
1382----------------------------------------------------
1383
1384Merge them into an iterator of tuples, sort the resulting list, and then pick
1385out the element you want. ::
1386
1387   >>> list1 = ["what", "I'm", "sorting", "by"]
1388   >>> list2 = ["something", "else", "to", "sort"]
1389   >>> pairs = zip(list1, list2)
1390   >>> pairs = sorted(pairs)
1391   >>> pairs
1392   [("I'm", 'else'), ('by', 'sort'), ('sorting', 'to'), ('what', 'something')]
1393   >>> result = [x[1] for x in pairs]
1394   >>> result
1395   ['else', 'sort', 'to', 'something']
1396
1397
1398Objects
1399=======
1400
1401What is a class?
1402----------------
1403
1404A class is the particular object type created by executing a class statement.
1405Class objects are used as templates to create instance objects, which embody
1406both the data (attributes) and code (methods) specific to a datatype.
1407
1408A class can be based on one or more other classes, called its base class(es). It
1409then inherits the attributes and methods of its base classes. This allows an
1410object model to be successively refined by inheritance.  You might have a
1411generic ``Mailbox`` class that provides basic accessor methods for a mailbox,
1412and subclasses such as ``MboxMailbox``, ``MaildirMailbox``, ``OutlookMailbox``
1413that handle various specific mailbox formats.
1414
1415
1416What is a method?
1417-----------------
1418
1419A method is a function on some object ``x`` that you normally call as
1420``x.name(arguments...)``.  Methods are defined as functions inside the class
1421definition::
1422
1423   class C:
1424       def meth(self, arg):
1425           return arg * 2 + self.attribute
1426
1427
1428What is self?
1429-------------
1430
1431Self is merely a conventional name for the first argument of a method.  A method
1432defined as ``meth(self, a, b, c)`` should be called as ``x.meth(a, b, c)`` for
1433some instance ``x`` of the class in which the definition occurs; the called
1434method will think it is called as ``meth(x, a, b, c)``.
1435
1436See also :ref:`why-self`.
1437
1438
1439How do I check if an object is an instance of a given class or of a subclass of it?
1440-----------------------------------------------------------------------------------
1441
1442Use the built-in function ``isinstance(obj, cls)``.  You can check if an object
1443is an instance of any of a number of classes by providing a tuple instead of a
1444single class, e.g. ``isinstance(obj, (class1, class2, ...))``, and can also
1445check whether an object is one of Python's built-in types, e.g.
1446``isinstance(obj, str)`` or ``isinstance(obj, (int, float, complex))``.
1447
1448Note that :func:`isinstance` also checks for virtual inheritance from an
1449:term:`abstract base class`.  So, the test will return ``True`` for a
1450registered class even if hasn't directly or indirectly inherited from it.  To
1451test for "true inheritance", scan the :term:`MRO` of the class:
1452
1453.. testcode::
1454
1455    from collections.abc import Mapping
1456
1457    class P:
1458         pass
1459
1460    class C(P):
1461        pass
1462
1463    Mapping.register(P)
1464
1465.. doctest::
1466
1467    >>> c = C()
1468    >>> isinstance(c, C)        # direct
1469    True
1470    >>> isinstance(c, P)        # indirect
1471    True
1472    >>> isinstance(c, Mapping)  # virtual
1473    True
1474
1475    # Actual inheritance chain
1476    >>> type(c).__mro__
1477    (<class 'C'>, <class 'P'>, <class 'object'>)
1478
1479    # Test for "true inheritance"
1480    >>> Mapping in type(c).__mro__
1481    False
1482
1483Note that most programs do not use :func:`isinstance` on user-defined classes
1484very often.  If you are developing the classes yourself, a more proper
1485object-oriented style is to define methods on the classes that encapsulate a
1486particular behaviour, instead of checking the object's class and doing a
1487different thing based on what class it is.  For example, if you have a function
1488that does something::
1489
1490   def search(obj):
1491       if isinstance(obj, Mailbox):
1492           ...  # code to search a mailbox
1493       elif isinstance(obj, Document):
1494           ...  # code to search a document
1495       elif ...
1496
1497A better approach is to define a ``search()`` method on all the classes and just
1498call it::
1499
1500   class Mailbox:
1501       def search(self):
1502           ...  # code to search a mailbox
1503
1504   class Document:
1505       def search(self):
1506           ...  # code to search a document
1507
1508   obj.search()
1509
1510
1511What is delegation?
1512-------------------
1513
1514Delegation is an object oriented technique (also called a design pattern).
1515Let's say you have an object ``x`` and want to change the behaviour of just one
1516of its methods.  You can create a new class that provides a new implementation
1517of the method you're interested in changing and delegates all other methods to
1518the corresponding method of ``x``.
1519
1520Python programmers can easily implement delegation.  For example, the following
1521class implements a class that behaves like a file but converts all written data
1522to uppercase::
1523
1524   class UpperOut:
1525
1526       def __init__(self, outfile):
1527           self._outfile = outfile
1528
1529       def write(self, s):
1530           self._outfile.write(s.upper())
1531
1532       def __getattr__(self, name):
1533           return getattr(self._outfile, name)
1534
1535Here the ``UpperOut`` class redefines the ``write()`` method to convert the
1536argument string to uppercase before calling the underlying
1537``self._outfile.write()`` method.  All other methods are delegated to the
1538underlying ``self._outfile`` object.  The delegation is accomplished via the
1539``__getattr__`` method; consult :ref:`the language reference <attribute-access>`
1540for more information about controlling attribute access.
1541
1542Note that for more general cases delegation can get trickier. When attributes
1543must be set as well as retrieved, the class must define a :meth:`__setattr__`
1544method too, and it must do so carefully.  The basic implementation of
1545:meth:`__setattr__` is roughly equivalent to the following::
1546
1547   class X:
1548       ...
1549       def __setattr__(self, name, value):
1550           self.__dict__[name] = value
1551       ...
1552
1553Most :meth:`__setattr__` implementations must modify ``self.__dict__`` to store
1554local state for self without causing an infinite recursion.
1555
1556
1557How do I call a method defined in a base class from a derived class that extends it?
1558------------------------------------------------------------------------------------
1559
1560Use the built-in :func:`super` function::
1561
1562   class Derived(Base):
1563       def meth(self):
1564           super().meth()  # calls Base.meth
1565
1566In the example, :func:`super` will automatically determine the instance from
1567which it was called (the ``self`` value), look up the :term:`method resolution
1568order` (MRO) with ``type(self).__mro__``, and return the next in line after
1569``Derived`` in the MRO: ``Base``.
1570
1571
1572How can I organize my code to make it easier to change the base class?
1573----------------------------------------------------------------------
1574
1575You could assign the base class to an alias and derive from the alias.  Then all
1576you have to change is the value assigned to the alias.  Incidentally, this trick
1577is also handy if you want to decide dynamically (e.g. depending on availability
1578of resources) which base class to use.  Example::
1579
1580   class Base:
1581       ...
1582
1583   BaseAlias = Base
1584
1585   class Derived(BaseAlias):
1586       ...
1587
1588
1589How do I create static class data and static class methods?
1590-----------------------------------------------------------
1591
1592Both static data and static methods (in the sense of C++ or Java) are supported
1593in Python.
1594
1595For static data, simply define a class attribute.  To assign a new value to the
1596attribute, you have to explicitly use the class name in the assignment::
1597
1598   class C:
1599       count = 0   # number of times C.__init__ called
1600
1601       def __init__(self):
1602           C.count = C.count + 1
1603
1604       def getcount(self):
1605           return C.count  # or return self.count
1606
1607``c.count`` also refers to ``C.count`` for any ``c`` such that ``isinstance(c,
1608C)`` holds, unless overridden by ``c`` itself or by some class on the base-class
1609search path from ``c.__class__`` back to ``C``.
1610
1611Caution: within a method of C, an assignment like ``self.count = 42`` creates a
1612new and unrelated instance named "count" in ``self``'s own dict.  Rebinding of a
1613class-static data name must always specify the class whether inside a method or
1614not::
1615
1616   C.count = 314
1617
1618Static methods are possible::
1619
1620   class C:
1621       @staticmethod
1622       def static(arg1, arg2, arg3):
1623           # No 'self' parameter!
1624           ...
1625
1626However, a far more straightforward way to get the effect of a static method is
1627via a simple module-level function::
1628
1629   def getcount():
1630       return C.count
1631
1632If your code is structured so as to define one class (or tightly related class
1633hierarchy) per module, this supplies the desired encapsulation.
1634
1635
1636How can I overload constructors (or methods) in Python?
1637-------------------------------------------------------
1638
1639This answer actually applies to all methods, but the question usually comes up
1640first in the context of constructors.
1641
1642In C++ you'd write
1643
1644.. code-block:: c
1645
1646    class C {
1647        C() { cout << "No arguments\n"; }
1648        C(int i) { cout << "Argument is " << i << "\n"; }
1649    }
1650
1651In Python you have to write a single constructor that catches all cases using
1652default arguments.  For example::
1653
1654   class C:
1655       def __init__(self, i=None):
1656           if i is None:
1657               print("No arguments")
1658           else:
1659               print("Argument is", i)
1660
1661This is not entirely equivalent, but close enough in practice.
1662
1663You could also try a variable-length argument list, e.g. ::
1664
1665   def __init__(self, *args):
1666       ...
1667
1668The same approach works for all method definitions.
1669
1670
1671I try to use __spam and I get an error about _SomeClassName__spam.
1672------------------------------------------------------------------
1673
1674Variable names with double leading underscores are "mangled" to provide a simple
1675but effective way to define class private variables.  Any identifier of the form
1676``__spam`` (at least two leading underscores, at most one trailing underscore)
1677is textually replaced with ``_classname__spam``, where ``classname`` is the
1678current class name with any leading underscores stripped.
1679
1680This doesn't guarantee privacy: an outside user can still deliberately access
1681the "_classname__spam" attribute, and private values are visible in the object's
1682``__dict__``.  Many Python programmers never bother to use private variable
1683names at all.
1684
1685
1686My class defines __del__ but it is not called when I delete the object.
1687-----------------------------------------------------------------------
1688
1689There are several possible reasons for this.
1690
1691The del statement does not necessarily call :meth:`__del__` -- it simply
1692decrements the object's reference count, and if this reaches zero
1693:meth:`__del__` is called.
1694
1695If your data structures contain circular links (e.g. a tree where each child has
1696a parent reference and each parent has a list of children) the reference counts
1697will never go back to zero.  Once in a while Python runs an algorithm to detect
1698such cycles, but the garbage collector might run some time after the last
1699reference to your data structure vanishes, so your :meth:`__del__` method may be
1700called at an inconvenient and random time. This is inconvenient if you're trying
1701to reproduce a problem. Worse, the order in which object's :meth:`__del__`
1702methods are executed is arbitrary.  You can run :func:`gc.collect` to force a
1703collection, but there *are* pathological cases where objects will never be
1704collected.
1705
1706Despite the cycle collector, it's still a good idea to define an explicit
1707``close()`` method on objects to be called whenever you're done with them.  The
1708``close()`` method can then remove attributes that refer to subobjects.  Don't
1709call :meth:`__del__` directly -- :meth:`__del__` should call ``close()`` and
1710``close()`` should make sure that it can be called more than once for the same
1711object.
1712
1713Another way to avoid cyclical references is to use the :mod:`weakref` module,
1714which allows you to point to objects without incrementing their reference count.
1715Tree data structures, for instance, should use weak references for their parent
1716and sibling references (if they need them!).
1717
1718.. XXX relevant for Python 3?
1719
1720   If the object has ever been a local variable in a function that caught an
1721   expression in an except clause, chances are that a reference to the object
1722   still exists in that function's stack frame as contained in the stack trace.
1723   Normally, calling :func:`sys.exc_clear` will take care of this by clearing
1724   the last recorded exception.
1725
1726Finally, if your :meth:`__del__` method raises an exception, a warning message
1727is printed to :data:`sys.stderr`.
1728
1729
1730How do I get a list of all instances of a given class?
1731------------------------------------------------------
1732
1733Python does not keep track of all instances of a class (or of a built-in type).
1734You can program the class's constructor to keep track of all instances by
1735keeping a list of weak references to each instance.
1736
1737
1738Why does the result of ``id()`` appear to be not unique?
1739--------------------------------------------------------
1740
1741The :func:`id` builtin returns an integer that is guaranteed to be unique during
1742the lifetime of the object.  Since in CPython, this is the object's memory
1743address, it happens frequently that after an object is deleted from memory, the
1744next freshly created object is allocated at the same position in memory.  This
1745is illustrated by this example:
1746
1747>>> id(1000) # doctest: +SKIP
174813901272
1749>>> id(2000) # doctest: +SKIP
175013901272
1751
1752The two ids belong to different integer objects that are created before, and
1753deleted immediately after execution of the ``id()`` call.  To be sure that
1754objects whose id you want to examine are still alive, create another reference
1755to the object:
1756
1757>>> a = 1000; b = 2000
1758>>> id(a) # doctest: +SKIP
175913901272
1760>>> id(b) # doctest: +SKIP
176113891296
1762
1763
1764When can I rely on identity tests with the *is* operator?
1765---------------------------------------------------------
1766
1767The ``is`` operator tests for object identity.  The test ``a is b`` is
1768equivalent to ``id(a) == id(b)``.
1769
1770The most important property of an identity test is that an object is always
1771identical to itself, ``a is a`` always returns ``True``.  Identity tests are
1772usually faster than equality tests.  And unlike equality tests, identity tests
1773are guaranteed to return a boolean ``True`` or ``False``.
1774
1775However, identity tests can *only* be substituted for equality tests when
1776object identity is assured.  Generally, there are three circumstances where
1777identity is guaranteed:
1778
17791) Assignments create new names but do not change object identity.  After the
1780assignment ``new = old``, it is guaranteed that ``new is old``.
1781
17822) Putting an object in a container that stores object references does not
1783change object identity.  After the list assignment ``s[0] = x``, it is
1784guaranteed that ``s[0] is x``.
1785
17863) If an object is a singleton, it means that only one instance of that object
1787can exist.  After the assignments ``a = None`` and ``b = None``, it is
1788guaranteed that ``a is b`` because ``None`` is a singleton.
1789
1790In most other circumstances, identity tests are inadvisable and equality tests
1791are preferred.  In particular, identity tests should not be used to check
1792constants such as :class:`int` and :class:`str` which aren't guaranteed to be
1793singletons::
1794
1795    >>> a = 1000
1796    >>> b = 500
1797    >>> c = b + 500
1798    >>> a is c
1799    False
1800
1801    >>> a = 'Python'
1802    >>> b = 'Py'
1803    >>> c = b + 'thon'
1804    >>> a is c
1805    False
1806
1807Likewise, new instances of mutable containers are never identical::
1808
1809    >>> a = []
1810    >>> b = []
1811    >>> a is b
1812    False
1813
1814In the standard library code, you will see several common patterns for
1815correctly using identity tests:
1816
18171) As recommended by :pep:`8`, an identity test is the preferred way to check
1818for ``None``.  This reads like plain English in code and avoids confusion with
1819other objects that may have boolean values that evaluate to false.
1820
18212) Detecting optional arguments can be tricky when ``None`` is a valid input
1822value.  In those situations, you can create an singleton sentinel object
1823guaranteed to be distinct from other objects.  For example, here is how
1824to implement a method that behaves like :meth:`dict.pop`::
1825
1826   _sentinel = object()
1827
1828   def pop(self, key, default=_sentinel):
1829       if key in self:
1830           value = self[key]
1831           del self[key]
1832           return value
1833       if default is _sentinel:
1834           raise KeyError(key)
1835       return default
1836
18373) Container implementations sometimes need to augment equality tests with
1838identity tests.  This prevents the code from being confused by objects such as
1839``float('NaN')`` that are not equal to themselves.
1840
1841For example, here is the implementation of
1842:meth:`collections.abc.Sequence.__contains__`::
1843
1844    def __contains__(self, value):
1845        for v in self:
1846            if v is value or v == value:
1847                return True
1848        return False
1849
1850
1851How can a subclass control what data is stored in an immutable instance?
1852------------------------------------------------------------------------
1853
1854When subclassing an immutable type, override the :meth:`__new__` method
1855instead of the :meth:`__init__` method.  The latter only runs *after* an
1856instance is created, which is too late to alter data in an immutable
1857instance.
1858
1859All of these immutable classes have a different signature than their
1860parent class:
1861
1862.. testcode::
1863
1864    from datetime import date
1865
1866    class FirstOfMonthDate(date):
1867        "Always choose the first day of the month"
1868        def __new__(cls, year, month, day):
1869            return super().__new__(cls, year, month, 1)
1870
1871    class NamedInt(int):
1872        "Allow text names for some numbers"
1873        xlat = {'zero': 0, 'one': 1, 'ten': 10}
1874        def __new__(cls, value):
1875            value = cls.xlat.get(value, value)
1876            return super().__new__(cls, value)
1877
1878    class TitleStr(str):
1879        "Convert str to name suitable for a URL path"
1880        def __new__(cls, s):
1881            s = s.lower().replace(' ', '-')
1882            s = ''.join([c for c in s if c.isalnum() or c == '-'])
1883            return super().__new__(cls, s)
1884
1885The classes can be used like this:
1886
1887.. doctest::
1888
1889    >>> FirstOfMonthDate(2012, 2, 14)
1890    FirstOfMonthDate(2012, 2, 1)
1891    >>> NamedInt('ten')
1892    10
1893    >>> NamedInt(20)
1894    20
1895    >>> TitleStr('Blog: Why Python Rocks')
1896    'blog-why-python-rocks'
1897
1898
1899How do I cache method calls?
1900----------------------------
1901
1902The two principal tools for caching methods are
1903:func:`functools.cached_property` and :func:`functools.lru_cache`.  The
1904former stores results at the instance level and the latter at the class
1905level.
1906
1907The *cached_property* approach only works with methods that do not take
1908any arguments.  It does not create a reference to the instance.  The
1909cached method result will be kept only as long as the instance is alive.
1910
1911The advantage is that when an instance is not longer used, the cached
1912method result will be released right away.  The disadvantage is that if
1913instances accumulate, so too will the accumulated method results.  They
1914can grow without bound.
1915
1916The *lru_cache* approach works with methods that have hashable
1917arguments.  It creates a reference to the instance unless special
1918efforts are made to pass in weak references.
1919
1920The advantage of the least recently used algorithm is that the cache is
1921bounded by the specified *maxsize*.  The disadvantage is that instances
1922are kept alive until they age out of the cache or until the cache is
1923cleared.
1924
1925This example shows the various techniques::
1926
1927    class Weather:
1928        "Lookup weather information on a government website"
1929
1930        def __init__(self, station_id):
1931            self._station_id = station_id
1932            # The _station_id is private and immutable
1933
1934        def current_temperature(self):
1935            "Latest hourly observation"
1936            # Do not cache this because old results
1937            # can be out of date.
1938
1939        @cached_property
1940        def location(self):
1941            "Return the longitude/latitude coordinates of the station"
1942            # Result only depends on the station_id
1943
1944        @lru_cache(maxsize=20)
1945        def historic_rainfall(self, date, units='mm'):
1946            "Rainfall on a given date"
1947            # Depends on the station_id, date, and units.
1948
1949The above example assumes that the *station_id* never changes.  If the
1950relevant instance attributes are mutable, the *cached_property* approach
1951can't be made to work because it cannot detect changes to the
1952attributes.
1953
1954The *lru_cache* approach can be made to work, but the class needs to define the
1955*__eq__* and *__hash__* methods so the cache can detect relevant attribute
1956updates::
1957
1958    class Weather:
1959        "Example with a mutable station identifier"
1960
1961        def __init__(self, station_id):
1962            self.station_id = station_id
1963
1964        def change_station(self, station_id):
1965            self.station_id = station_id
1966
1967        def __eq__(self, other):
1968            return self.station_id == other.station_id
1969
1970        def __hash__(self):
1971            return hash(self.station_id)
1972
1973        @lru_cache(maxsize=20)
1974        def historic_rainfall(self, date, units='cm'):
1975            'Rainfall on a given date'
1976            # Depends on the station_id, date, and units.
1977
1978
1979Modules
1980=======
1981
1982How do I create a .pyc file?
1983----------------------------
1984
1985When a module is imported for the first time (or when the source file has
1986changed since the current compiled file was created) a ``.pyc`` file containing
1987the compiled code should be created in a ``__pycache__`` subdirectory of the
1988directory containing the ``.py`` file.  The ``.pyc`` file will have a
1989filename that starts with the same name as the ``.py`` file, and ends with
1990``.pyc``, with a middle component that depends on the particular ``python``
1991binary that created it.  (See :pep:`3147` for details.)
1992
1993One reason that a ``.pyc`` file may not be created is a permissions problem
1994with the directory containing the source file, meaning that the ``__pycache__``
1995subdirectory cannot be created. This can happen, for example, if you develop as
1996one user but run as another, such as if you are testing with a web server.
1997
1998Unless the :envvar:`PYTHONDONTWRITEBYTECODE` environment variable is set,
1999creation of a .pyc file is automatic if you're importing a module and Python
2000has the ability (permissions, free space, etc...) to create a ``__pycache__``
2001subdirectory and write the compiled module to that subdirectory.
2002
2003Running Python on a top level script is not considered an import and no
2004``.pyc`` will be created.  For example, if you have a top-level module
2005``foo.py`` that imports another module ``xyz.py``, when you run ``foo`` (by
2006typing ``python foo.py`` as a shell command), a ``.pyc`` will be created for
2007``xyz`` because ``xyz`` is imported, but no ``.pyc`` file will be created for
2008``foo`` since ``foo.py`` isn't being imported.
2009
2010If you need to create a ``.pyc`` file for ``foo`` -- that is, to create a
2011``.pyc`` file for a module that is not imported -- you can, using the
2012:mod:`py_compile` and :mod:`compileall` modules.
2013
2014The :mod:`py_compile` module can manually compile any module.  One way is to use
2015the ``compile()`` function in that module interactively::
2016
2017   >>> import py_compile
2018   >>> py_compile.compile('foo.py')                 # doctest: +SKIP
2019
2020This will write the ``.pyc`` to a ``__pycache__`` subdirectory in the same
2021location as ``foo.py`` (or you can override that with the optional parameter
2022``cfile``).
2023
2024You can also automatically compile all files in a directory or directories using
2025the :mod:`compileall` module.  You can do it from the shell prompt by running
2026``compileall.py`` and providing the path of a directory containing Python files
2027to compile::
2028
2029       python -m compileall .
2030
2031
2032How do I find the current module name?
2033--------------------------------------
2034
2035A module can find out its own module name by looking at the predefined global
2036variable ``__name__``.  If this has the value ``'__main__'``, the program is
2037running as a script.  Many modules that are usually used by importing them also
2038provide a command-line interface or a self-test, and only execute this code
2039after checking ``__name__``::
2040
2041   def main():
2042       print('Running test...')
2043       ...
2044
2045   if __name__ == '__main__':
2046       main()
2047
2048
2049How can I have modules that mutually import each other?
2050-------------------------------------------------------
2051
2052Suppose you have the following modules:
2053
2054:file:`foo.py`::
2055
2056   from bar import bar_var
2057   foo_var = 1
2058
2059:file:`bar.py`::
2060
2061   from foo import foo_var
2062   bar_var = 2
2063
2064The problem is that the interpreter will perform the following steps:
2065
2066* main imports ``foo``
2067* Empty globals for ``foo`` are created
2068* ``foo`` is compiled and starts executing
2069* ``foo`` imports ``bar``
2070* Empty globals for ``bar`` are created
2071* ``bar`` is compiled and starts executing
2072* ``bar`` imports ``foo`` (which is a no-op since there already is a module named ``foo``)
2073* The import mechanism tries to read ``foo_var`` from ``foo`` globals, to set ``bar.foo_var = foo.foo_var``
2074
2075The last step fails, because Python isn't done with interpreting ``foo`` yet and
2076the global symbol dictionary for ``foo`` is still empty.
2077
2078The same thing happens when you use ``import foo``, and then try to access
2079``foo.foo_var`` in global code.
2080
2081There are (at least) three possible workarounds for this problem.
2082
2083Guido van Rossum recommends avoiding all uses of ``from <module> import ...``,
2084and placing all code inside functions.  Initializations of global variables and
2085class variables should use constants or built-in functions only.  This means
2086everything from an imported module is referenced as ``<module>.<name>``.
2087
2088Jim Roskind suggests performing steps in the following order in each module:
2089
2090* exports (globals, functions, and classes that don't need imported base
2091  classes)
2092* ``import`` statements
2093* active code (including globals that are initialized from imported values).
2094
2095Van Rossum doesn't like this approach much because the imports appear in a
2096strange place, but it does work.
2097
2098Matthias Urlichs recommends restructuring your code so that the recursive import
2099is not necessary in the first place.
2100
2101These solutions are not mutually exclusive.
2102
2103
2104__import__('x.y.z') returns <module 'x'>; how do I get z?
2105---------------------------------------------------------
2106
2107Consider using the convenience function :func:`~importlib.import_module` from
2108:mod:`importlib` instead::
2109
2110   z = importlib.import_module('x.y.z')
2111
2112
2113When I edit an imported module and reimport it, the changes don't show up.  Why does this happen?
2114-------------------------------------------------------------------------------------------------
2115
2116For reasons of efficiency as well as consistency, Python only reads the module
2117file on the first time a module is imported.  If it didn't, in a program
2118consisting of many modules where each one imports the same basic module, the
2119basic module would be parsed and re-parsed many times.  To force re-reading of a
2120changed module, do this::
2121
2122   import importlib
2123   import modname
2124   importlib.reload(modname)
2125
2126Warning: this technique is not 100% fool-proof.  In particular, modules
2127containing statements like ::
2128
2129   from modname import some_objects
2130
2131will continue to work with the old version of the imported objects.  If the
2132module contains class definitions, existing class instances will *not* be
2133updated to use the new class definition.  This can result in the following
2134paradoxical behaviour::
2135
2136   >>> import importlib
2137   >>> import cls
2138   >>> c = cls.C()                # Create an instance of C
2139   >>> importlib.reload(cls)
2140   <module 'cls' from 'cls.py'>
2141   >>> isinstance(c, cls.C)       # isinstance is false?!?
2142   False
2143
2144The nature of the problem is made clear if you print out the "identity" of the
2145class objects::
2146
2147   >>> hex(id(c.__class__))
2148   '0x7352a0'
2149   >>> hex(id(cls.C))
2150   '0x4198d0'
2151