[2] | 1 | :tocdepth: 2
|
---|
| 2 |
|
---|
| 3 | ===============
|
---|
| 4 | Programming FAQ
|
---|
| 5 | ===============
|
---|
| 6 |
|
---|
[391] | 7 | .. only:: html
|
---|
[2] | 8 |
|
---|
[391] | 9 | .. contents::
|
---|
| 10 |
|
---|
[2] | 11 | General Questions
|
---|
| 12 | =================
|
---|
| 13 |
|
---|
| 14 | Is there a source code level debugger with breakpoints, single-stepping, etc.?
|
---|
| 15 | ------------------------------------------------------------------------------
|
---|
| 16 |
|
---|
| 17 | Yes.
|
---|
| 18 |
|
---|
| 19 | The pdb module is a simple but adequate console-mode debugger for Python. It is
|
---|
| 20 | part of the standard Python library, and is :mod:`documented in the Library
|
---|
| 21 | Reference Manual <pdb>`. You can also write your own debugger by using the code
|
---|
| 22 | for pdb as an example.
|
---|
| 23 |
|
---|
| 24 | The IDLE interactive development environment, which is part of the standard
|
---|
| 25 | Python distribution (normally available as Tools/scripts/idle), includes a
|
---|
| 26 | graphical debugger. There is documentation for the IDLE debugger at
|
---|
| 27 | http://www.python.org/idle/doc/idle2.html#Debugger.
|
---|
| 28 |
|
---|
| 29 | PythonWin is a Python IDE that includes a GUI debugger based on pdb. The
|
---|
| 30 | Pythonwin debugger colors breakpoints and has quite a few cool features such as
|
---|
| 31 | debugging non-Pythonwin programs. Pythonwin is available as part of the `Python
|
---|
| 32 | for Windows Extensions <http://sourceforge.net/projects/pywin32/>`__ project and
|
---|
| 33 | as a part of the ActivePython distribution (see
|
---|
| 34 | http://www.activestate.com/Products/ActivePython/index.html).
|
---|
| 35 |
|
---|
| 36 | `Boa Constructor <http://boa-constructor.sourceforge.net/>`_ is an IDE and GUI
|
---|
| 37 | builder that uses wxWidgets. It offers visual frame creation and manipulation,
|
---|
| 38 | an object inspector, many views on the source like object browsers, inheritance
|
---|
| 39 | hierarchies, doc string generated html documentation, an advanced debugger,
|
---|
| 40 | integrated help, and Zope support.
|
---|
| 41 |
|
---|
| 42 | `Eric <http://www.die-offenbachs.de/eric/index.html>`_ is an IDE built on PyQt
|
---|
| 43 | and the Scintilla editing component.
|
---|
| 44 |
|
---|
| 45 | Pydb is a version of the standard Python debugger pdb, modified for use with DDD
|
---|
| 46 | (Data Display Debugger), a popular graphical debugger front end. Pydb can be
|
---|
| 47 | found at http://bashdb.sourceforge.net/pydb/ and DDD can be found at
|
---|
| 48 | http://www.gnu.org/software/ddd.
|
---|
| 49 |
|
---|
| 50 | There are a number of commercial Python IDEs that include graphical debuggers.
|
---|
| 51 | They include:
|
---|
| 52 |
|
---|
| 53 | * Wing IDE (http://wingware.com/)
|
---|
| 54 | * Komodo IDE (http://www.activestate.com/Products/Komodo)
|
---|
| 55 |
|
---|
| 56 |
|
---|
| 57 | Is there a tool to help find bugs or perform static analysis?
|
---|
| 58 | -------------------------------------------------------------
|
---|
| 59 |
|
---|
| 60 | Yes.
|
---|
| 61 |
|
---|
| 62 | PyChecker is a static analysis tool that finds bugs in Python source code and
|
---|
| 63 | warns about code complexity and style. You can get PyChecker from
|
---|
| 64 | http://pychecker.sf.net.
|
---|
| 65 |
|
---|
| 66 | `Pylint <http://www.logilab.org/projects/pylint>`_ is another tool that checks
|
---|
| 67 | if a module satisfies a coding standard, and also makes it possible to write
|
---|
| 68 | plug-ins to add a custom feature. In addition to the bug checking that
|
---|
| 69 | PyChecker performs, Pylint offers some additional features such as checking line
|
---|
| 70 | length, whether variable names are well-formed according to your coding
|
---|
| 71 | standard, whether declared interfaces are fully implemented, and more.
|
---|
| 72 | http://www.logilab.org/card/pylint_manual provides a full list of Pylint's
|
---|
| 73 | features.
|
---|
| 74 |
|
---|
| 75 |
|
---|
| 76 | How can I create a stand-alone binary from a Python script?
|
---|
| 77 | -----------------------------------------------------------
|
---|
| 78 |
|
---|
| 79 | You don't need the ability to compile Python to C code if all you want is a
|
---|
| 80 | stand-alone program that users can download and run without having to install
|
---|
| 81 | the Python distribution first. There are a number of tools that determine the
|
---|
| 82 | set of modules required by a program and bind these modules together with a
|
---|
| 83 | Python binary to produce a single executable.
|
---|
| 84 |
|
---|
| 85 | One is to use the freeze tool, which is included in the Python source tree as
|
---|
| 86 | ``Tools/freeze``. It converts Python byte code to C arrays; a C compiler you can
|
---|
| 87 | embed all your modules into a new program, which is then linked with the
|
---|
| 88 | standard Python modules.
|
---|
| 89 |
|
---|
| 90 | It works by scanning your source recursively for import statements (in both
|
---|
| 91 | forms) and looking for the modules in the standard Python path as well as in the
|
---|
| 92 | source directory (for built-in modules). It then turns the bytecode for modules
|
---|
| 93 | written in Python into C code (array initializers that can be turned into code
|
---|
| 94 | objects using the marshal module) and creates a custom-made config file that
|
---|
| 95 | only contains those built-in modules which are actually used in the program. It
|
---|
| 96 | then compiles the generated C code and links it with the rest of the Python
|
---|
| 97 | interpreter to form a self-contained binary which acts exactly like your script.
|
---|
| 98 |
|
---|
| 99 | Obviously, freeze requires a C compiler. There are several other utilities
|
---|
| 100 | which don't. One is Thomas Heller's py2exe (Windows only) at
|
---|
| 101 |
|
---|
| 102 | http://www.py2exe.org/
|
---|
| 103 |
|
---|
| 104 | Another is Christian Tismer's `SQFREEZE <http://starship.python.net/crew/pirx>`_
|
---|
| 105 | which appends the byte code to a specially-prepared Python interpreter that can
|
---|
| 106 | find the byte code in the executable.
|
---|
| 107 |
|
---|
| 108 | Other tools include Fredrik Lundh's `Squeeze
|
---|
| 109 | <http://www.pythonware.com/products/python/squeeze>`_ and Anthony Tuininga's
|
---|
| 110 | `cx_Freeze <http://starship.python.net/crew/atuining/cx_Freeze/index.html>`_.
|
---|
| 111 |
|
---|
| 112 |
|
---|
| 113 | Are there coding standards or a style guide for Python programs?
|
---|
| 114 | ----------------------------------------------------------------
|
---|
| 115 |
|
---|
| 116 | Yes. The coding style required for standard library modules is documented as
|
---|
| 117 | :pep:`8`.
|
---|
| 118 |
|
---|
| 119 |
|
---|
| 120 | My program is too slow. How do I speed it up?
|
---|
| 121 | ---------------------------------------------
|
---|
| 122 |
|
---|
| 123 | That's a tough one, in general. There are many tricks to speed up Python code;
|
---|
| 124 | consider rewriting parts in C as a last resort.
|
---|
| 125 |
|
---|
| 126 | In some cases it's possible to automatically translate Python to C or x86
|
---|
| 127 | assembly language, meaning that you don't have to modify your code to gain
|
---|
| 128 | increased speed.
|
---|
| 129 |
|
---|
| 130 | .. XXX seems to have overlap with other questions!
|
---|
| 131 |
|
---|
| 132 | `Pyrex <http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/>`_ can compile a
|
---|
| 133 | slightly modified version of Python code into a C extension, and can be used on
|
---|
| 134 | many different platforms.
|
---|
| 135 |
|
---|
| 136 | `Psyco <http://psyco.sourceforge.net>`_ is a just-in-time compiler that
|
---|
| 137 | translates Python code into x86 assembly language. If you can use it, Psyco can
|
---|
| 138 | provide dramatic speedups for critical functions.
|
---|
| 139 |
|
---|
| 140 | The rest of this answer will discuss various tricks for squeezing a bit more
|
---|
| 141 | speed out of Python code. *Never* apply any optimization tricks unless you know
|
---|
| 142 | you need them, after profiling has indicated that a particular function is the
|
---|
| 143 | heavily executed hot spot in the code. Optimizations almost always make the
|
---|
| 144 | code less clear, and you shouldn't pay the costs of reduced clarity (increased
|
---|
| 145 | development time, greater likelihood of bugs) unless the resulting performance
|
---|
| 146 | benefit is worth it.
|
---|
| 147 |
|
---|
| 148 | There is a page on the wiki devoted to `performance tips
|
---|
| 149 | <http://wiki.python.org/moin/PythonSpeed/PerformanceTips>`_.
|
---|
| 150 |
|
---|
| 151 | Guido van Rossum has written up an anecdote related to optimization at
|
---|
| 152 | http://www.python.org/doc/essays/list2str.html.
|
---|
| 153 |
|
---|
| 154 | One thing to notice is that function and (especially) method calls are rather
|
---|
| 155 | expensive; if you have designed a purely OO interface with lots of tiny
|
---|
| 156 | functions that don't do much more than get or set an instance variable or call
|
---|
| 157 | another method, you might consider using a more direct way such as directly
|
---|
| 158 | accessing instance variables. Also see the standard module :mod:`profile` which
|
---|
| 159 | makes it possible to find out where your program is spending most of its time
|
---|
| 160 | (if you have some patience -- the profiling itself can slow your program down by
|
---|
| 161 | an order of magnitude).
|
---|
| 162 |
|
---|
| 163 | Remember that many standard optimization heuristics you may know from other
|
---|
| 164 | programming experience may well apply to Python. For example it may be faster
|
---|
| 165 | to send output to output devices using larger writes rather than smaller ones in
|
---|
| 166 | order to reduce the overhead of kernel system calls. Thus CGI scripts that
|
---|
| 167 | write all output in "one shot" may be faster than those that write lots of small
|
---|
| 168 | pieces of output.
|
---|
| 169 |
|
---|
| 170 | Also, be sure to use Python's core features where appropriate. For example,
|
---|
| 171 | slicing allows programs to chop up lists and other sequence objects in a single
|
---|
| 172 | tick of the interpreter's mainloop using highly optimized C implementations.
|
---|
| 173 | Thus to get the same effect as::
|
---|
| 174 |
|
---|
| 175 | L2 = []
|
---|
[391] | 176 | for i in range(3):
|
---|
[2] | 177 | L2.append(L1[i])
|
---|
| 178 |
|
---|
| 179 | it is much shorter and far faster to use ::
|
---|
| 180 |
|
---|
[391] | 181 | L2 = list(L1[:3]) # "list" is redundant if L1 is a list.
|
---|
[2] | 182 |
|
---|
| 183 | Note that the functionally-oriented built-in functions such as :func:`map`,
|
---|
| 184 | :func:`zip`, and friends can be a convenient accelerator for loops that
|
---|
| 185 | perform a single task. For example to pair the elements of two lists
|
---|
| 186 | together::
|
---|
| 187 |
|
---|
[391] | 188 | >>> zip([1, 2, 3], [4, 5, 6])
|
---|
[2] | 189 | [(1, 4), (2, 5), (3, 6)]
|
---|
| 190 |
|
---|
| 191 | or to compute a number of sines::
|
---|
| 192 |
|
---|
[391] | 193 | >>> map(math.sin, (1, 2, 3, 4))
|
---|
| 194 | [0.841470984808, 0.909297426826, 0.14112000806, -0.756802495308]
|
---|
[2] | 195 |
|
---|
| 196 | The operation completes very quickly in such cases.
|
---|
| 197 |
|
---|
[391] | 198 | Other examples include the ``join()`` and ``split()`` :ref:`methods
|
---|
| 199 | of string objects <string-methods>`.
|
---|
[2] | 200 | For example if s1..s7 are large (10K+) strings then
|
---|
| 201 | ``"".join([s1,s2,s3,s4,s5,s6,s7])`` may be far faster than the more obvious
|
---|
| 202 | ``s1+s2+s3+s4+s5+s6+s7``, since the "summation" will compute many
|
---|
| 203 | subexpressions, whereas ``join()`` does all the copying in one pass. For
|
---|
[391] | 204 | manipulating strings, use the ``replace()`` and the ``format()`` :ref:`methods
|
---|
| 205 | on string objects <string-methods>`. Use regular expressions only when you're
|
---|
| 206 | not dealing with constant string patterns. You may still use :ref:`the old %
|
---|
| 207 | operations <string-formatting>` ``string % tuple`` and ``string % dictionary``.
|
---|
[2] | 208 |
|
---|
| 209 | Be sure to use the :meth:`list.sort` built-in method to do sorting, and see the
|
---|
| 210 | `sorting mini-HOWTO <http://wiki.python.org/moin/HowTo/Sorting>`_ for examples
|
---|
| 211 | of moderately advanced usage. :meth:`list.sort` beats other techniques for
|
---|
| 212 | sorting in all but the most extreme circumstances.
|
---|
| 213 |
|
---|
| 214 | Another common trick is to "push loops into functions or methods." For example
|
---|
| 215 | suppose you have a program that runs slowly and you use the profiler to
|
---|
| 216 | determine that a Python function ``ff()`` is being called lots of times. If you
|
---|
[391] | 217 | notice that ``ff()``::
|
---|
[2] | 218 |
|
---|
| 219 | def ff(x):
|
---|
| 220 | ... # do something with x computing result...
|
---|
| 221 | return result
|
---|
| 222 |
|
---|
| 223 | tends to be called in loops like::
|
---|
| 224 |
|
---|
| 225 | list = map(ff, oldlist)
|
---|
| 226 |
|
---|
| 227 | or::
|
---|
| 228 |
|
---|
| 229 | for x in sequence:
|
---|
| 230 | value = ff(x)
|
---|
| 231 | ... # do something with value...
|
---|
| 232 |
|
---|
| 233 | then you can often eliminate function call overhead by rewriting ``ff()`` to::
|
---|
| 234 |
|
---|
| 235 | def ffseq(seq):
|
---|
| 236 | resultseq = []
|
---|
| 237 | for x in seq:
|
---|
| 238 | ... # do something with x computing result...
|
---|
| 239 | resultseq.append(result)
|
---|
| 240 | return resultseq
|
---|
| 241 |
|
---|
| 242 | and rewrite the two examples to ``list = ffseq(oldlist)`` and to::
|
---|
| 243 |
|
---|
| 244 | for value in ffseq(sequence):
|
---|
| 245 | ... # do something with value...
|
---|
| 246 |
|
---|
| 247 | Single calls to ``ff(x)`` translate to ``ffseq([x])[0]`` with little penalty.
|
---|
| 248 | Of course this technique is not always appropriate and there are other variants
|
---|
| 249 | which you can figure out.
|
---|
| 250 |
|
---|
| 251 | You can gain some performance by explicitly storing the results of a function or
|
---|
| 252 | method lookup into a local variable. A loop like::
|
---|
| 253 |
|
---|
| 254 | for key in token:
|
---|
| 255 | dict[key] = dict.get(key, 0) + 1
|
---|
| 256 |
|
---|
| 257 | resolves ``dict.get`` every iteration. If the method isn't going to change, a
|
---|
| 258 | slightly faster implementation is::
|
---|
| 259 |
|
---|
| 260 | dict_get = dict.get # look up the method once
|
---|
| 261 | for key in token:
|
---|
| 262 | dict[key] = dict_get(key, 0) + 1
|
---|
| 263 |
|
---|
| 264 | Default arguments can be used to determine values once, at compile time instead
|
---|
| 265 | of at run time. This can only be done for functions or objects which will not
|
---|
| 266 | be changed during program execution, such as replacing ::
|
---|
| 267 |
|
---|
| 268 | def degree_sin(deg):
|
---|
| 269 | return math.sin(deg * math.pi / 180.0)
|
---|
| 270 |
|
---|
| 271 | with ::
|
---|
| 272 |
|
---|
| 273 | def degree_sin(deg, factor=math.pi/180.0, sin=math.sin):
|
---|
| 274 | return sin(deg * factor)
|
---|
| 275 |
|
---|
| 276 | Because this trick uses default arguments for terms which should not be changed,
|
---|
| 277 | it should only be used when you are not concerned with presenting a possibly
|
---|
| 278 | confusing API to your users.
|
---|
| 279 |
|
---|
| 280 |
|
---|
| 281 | Core Language
|
---|
| 282 | =============
|
---|
| 283 |
|
---|
| 284 | Why am I getting an UnboundLocalError when the variable has a value?
|
---|
| 285 | --------------------------------------------------------------------
|
---|
| 286 |
|
---|
| 287 | It can be a surprise to get the UnboundLocalError in previously working
|
---|
| 288 | code when it is modified by adding an assignment statement somewhere in
|
---|
| 289 | the body of a function.
|
---|
| 290 |
|
---|
| 291 | This code:
|
---|
| 292 |
|
---|
| 293 | >>> x = 10
|
---|
| 294 | >>> def bar():
|
---|
| 295 | ... print x
|
---|
| 296 | >>> bar()
|
---|
| 297 | 10
|
---|
| 298 |
|
---|
| 299 | works, but this code:
|
---|
| 300 |
|
---|
| 301 | >>> x = 10
|
---|
| 302 | >>> def foo():
|
---|
| 303 | ... print x
|
---|
| 304 | ... x += 1
|
---|
| 305 |
|
---|
| 306 | results in an UnboundLocalError:
|
---|
| 307 |
|
---|
| 308 | >>> foo()
|
---|
| 309 | Traceback (most recent call last):
|
---|
| 310 | ...
|
---|
| 311 | UnboundLocalError: local variable 'x' referenced before assignment
|
---|
| 312 |
|
---|
| 313 | This is because when you make an assignment to a variable in a scope, that
|
---|
| 314 | variable becomes local to that scope and shadows any similarly named variable
|
---|
| 315 | in the outer scope. Since the last statement in foo assigns a new value to
|
---|
| 316 | ``x``, the compiler recognizes it as a local variable. Consequently when the
|
---|
| 317 | earlier ``print x`` attempts to print the uninitialized local variable and
|
---|
| 318 | an error results.
|
---|
| 319 |
|
---|
| 320 | In the example above you can access the outer scope variable by declaring it
|
---|
| 321 | global:
|
---|
| 322 |
|
---|
| 323 | >>> x = 10
|
---|
| 324 | >>> def foobar():
|
---|
| 325 | ... global x
|
---|
| 326 | ... print x
|
---|
| 327 | ... x += 1
|
---|
| 328 | >>> foobar()
|
---|
| 329 | 10
|
---|
| 330 |
|
---|
| 331 | This explicit declaration is required in order to remind you that (unlike the
|
---|
| 332 | superficially analogous situation with class and instance variables) you are
|
---|
| 333 | actually modifying the value of the variable in the outer scope:
|
---|
| 334 |
|
---|
| 335 | >>> print x
|
---|
| 336 | 11
|
---|
| 337 |
|
---|
| 338 |
|
---|
| 339 | What are the rules for local and global variables in Python?
|
---|
| 340 | ------------------------------------------------------------
|
---|
| 341 |
|
---|
| 342 | In Python, variables that are only referenced inside a function are implicitly
|
---|
| 343 | global. If a variable is assigned a new value anywhere within the function's
|
---|
| 344 | body, it's assumed to be a local. If a variable is ever assigned a new value
|
---|
| 345 | inside the function, the variable is implicitly local, and you need to
|
---|
| 346 | explicitly declare it as 'global'.
|
---|
| 347 |
|
---|
| 348 | Though a bit surprising at first, a moment's consideration explains this. On
|
---|
| 349 | one hand, requiring :keyword:`global` for assigned variables provides a bar
|
---|
| 350 | against unintended side-effects. On the other hand, if ``global`` was required
|
---|
| 351 | for all global references, you'd be using ``global`` all the time. You'd have
|
---|
| 352 | to declare as global every reference to a built-in function or to a component of
|
---|
| 353 | an imported module. This clutter would defeat the usefulness of the ``global``
|
---|
| 354 | declaration for identifying side-effects.
|
---|
| 355 |
|
---|
| 356 |
|
---|
[391] | 357 | Why do lambdas defined in a loop with different values all return the same result?
|
---|
| 358 | ----------------------------------------------------------------------------------
|
---|
| 359 |
|
---|
| 360 | Assume you use a for loop to define a few different lambdas (or even plain
|
---|
| 361 | functions), e.g.::
|
---|
| 362 |
|
---|
| 363 | >>> squares = []
|
---|
| 364 | >>> for x in range(5):
|
---|
| 365 | ... squares.append(lambda: x**2)
|
---|
| 366 |
|
---|
| 367 | This gives you a list that contains 5 lambdas that calculate ``x**2``. You
|
---|
| 368 | might expect that, when called, they would return, respectively, ``0``, ``1``,
|
---|
| 369 | ``4``, ``9``, and ``16``. However, when you actually try you will see that
|
---|
| 370 | they all return ``16``::
|
---|
| 371 |
|
---|
| 372 | >>> squares[2]()
|
---|
| 373 | 16
|
---|
| 374 | >>> squares[4]()
|
---|
| 375 | 16
|
---|
| 376 |
|
---|
| 377 | This happens because ``x`` is not local to the lambdas, but is defined in
|
---|
| 378 | the outer scope, and it is accessed when the lambda is called --- not when it
|
---|
| 379 | is defined. At the end of the loop, the value of ``x`` is ``4``, so all the
|
---|
| 380 | functions now return ``4**2``, i.e. ``16``. You can also verify this by
|
---|
| 381 | changing the value of ``x`` and see how the results of the lambdas change::
|
---|
| 382 |
|
---|
| 383 | >>> x = 8
|
---|
| 384 | >>> squares[2]()
|
---|
| 385 | 64
|
---|
| 386 |
|
---|
| 387 | In order to avoid this, you need to save the values in variables local to the
|
---|
| 388 | lambdas, so that they don't rely on the value of the global ``x``::
|
---|
| 389 |
|
---|
| 390 | >>> squares = []
|
---|
| 391 | >>> for x in range(5):
|
---|
| 392 | ... squares.append(lambda n=x: n**2)
|
---|
| 393 |
|
---|
| 394 | Here, ``n=x`` creates a new variable ``n`` local to the lambda and computed
|
---|
| 395 | when the lambda is defined so that it has the same value that ``x`` had at
|
---|
| 396 | that point in the loop. This means that the value of ``n`` will be ``0``
|
---|
| 397 | in the first lambda, ``1`` in the second, ``2`` in the third, and so on.
|
---|
| 398 | Therefore each lambda will now return the correct result::
|
---|
| 399 |
|
---|
| 400 | >>> squares[2]()
|
---|
| 401 | 4
|
---|
| 402 | >>> squares[4]()
|
---|
| 403 | 16
|
---|
| 404 |
|
---|
| 405 | Note that this behaviour is not peculiar to lambdas, but applies to regular
|
---|
| 406 | functions too.
|
---|
| 407 |
|
---|
| 408 |
|
---|
[2] | 409 | How do I share global variables across modules?
|
---|
| 410 | ------------------------------------------------
|
---|
| 411 |
|
---|
| 412 | The canonical way to share information across modules within a single program is
|
---|
| 413 | to create a special module (often called config or cfg). Just import the config
|
---|
| 414 | module in all modules of your application; the module then becomes available as
|
---|
| 415 | a global name. Because there is only one instance of each module, any changes
|
---|
| 416 | made to the module object get reflected everywhere. For example:
|
---|
| 417 |
|
---|
| 418 | config.py::
|
---|
| 419 |
|
---|
| 420 | x = 0 # Default value of the 'x' configuration setting
|
---|
| 421 |
|
---|
| 422 | mod.py::
|
---|
| 423 |
|
---|
| 424 | import config
|
---|
| 425 | config.x = 1
|
---|
| 426 |
|
---|
| 427 | main.py::
|
---|
| 428 |
|
---|
| 429 | import config
|
---|
| 430 | import mod
|
---|
| 431 | print config.x
|
---|
| 432 |
|
---|
| 433 | Note that using a module is also the basis for implementing the Singleton design
|
---|
| 434 | pattern, for the same reason.
|
---|
| 435 |
|
---|
| 436 |
|
---|
| 437 | What are the "best practices" for using import in a module?
|
---|
| 438 | -----------------------------------------------------------
|
---|
| 439 |
|
---|
| 440 | In general, don't use ``from modulename import *``. Doing so clutters the
|
---|
| 441 | importer's namespace. Some people avoid this idiom even with the few modules
|
---|
| 442 | that were designed to be imported in this manner. Modules designed in this
|
---|
| 443 | manner include :mod:`Tkinter`, and :mod:`threading`.
|
---|
| 444 |
|
---|
| 445 | Import modules at the top of a file. Doing so makes it clear what other modules
|
---|
| 446 | your code requires and avoids questions of whether the module name is in scope.
|
---|
| 447 | Using one import per line makes it easy to add and delete module imports, but
|
---|
| 448 | using multiple imports per line uses less screen space.
|
---|
| 449 |
|
---|
| 450 | It's good practice if you import modules in the following order:
|
---|
| 451 |
|
---|
[391] | 452 | 1. standard library modules -- e.g. ``sys``, ``os``, ``getopt``, ``re``
|
---|
[2] | 453 | 2. third-party library modules (anything installed in Python's site-packages
|
---|
| 454 | directory) -- e.g. mx.DateTime, ZODB, PIL.Image, etc.
|
---|
| 455 | 3. locally-developed modules
|
---|
| 456 |
|
---|
| 457 | Never use relative package imports. If you're writing code that's in the
|
---|
| 458 | ``package.sub.m1`` module and want to import ``package.sub.m2``, do not just
|
---|
| 459 | write ``import m2``, even though it's legal. Write ``from package.sub import
|
---|
| 460 | m2`` instead. Relative imports can lead to a module being initialized twice,
|
---|
[391] | 461 | leading to confusing bugs. See :pep:`328` for details.
|
---|
[2] | 462 |
|
---|
| 463 | It is sometimes necessary to move imports to a function or class to avoid
|
---|
| 464 | problems with circular imports. Gordon McMillan says:
|
---|
| 465 |
|
---|
| 466 | Circular imports are fine where both modules use the "import <module>" form
|
---|
| 467 | of import. They fail when the 2nd module wants to grab a name out of the
|
---|
| 468 | first ("from module import name") and the import is at the top level. That's
|
---|
| 469 | because names in the 1st are not yet available, because the first module is
|
---|
| 470 | busy importing the 2nd.
|
---|
| 471 |
|
---|
| 472 | In this case, if the second module is only used in one function, then the import
|
---|
| 473 | can easily be moved into that function. By the time the import is called, the
|
---|
| 474 | first module will have finished initializing, and the second module can do its
|
---|
| 475 | import.
|
---|
| 476 |
|
---|
| 477 | It may also be necessary to move imports out of the top level of code if some of
|
---|
| 478 | the modules are platform-specific. In that case, it may not even be possible to
|
---|
| 479 | import all of the modules at the top of the file. In this case, importing the
|
---|
| 480 | correct modules in the corresponding platform-specific code is a good option.
|
---|
| 481 |
|
---|
| 482 | Only move imports into a local scope, such as inside a function definition, if
|
---|
| 483 | it's necessary to solve a problem such as avoiding a circular import or are
|
---|
| 484 | trying to reduce the initialization time of a module. This technique is
|
---|
| 485 | especially helpful if many of the imports are unnecessary depending on how the
|
---|
| 486 | program executes. You may also want to move imports into a function if the
|
---|
| 487 | modules are only ever used in that function. Note that loading a module the
|
---|
| 488 | first time may be expensive because of the one time initialization of the
|
---|
| 489 | module, but loading a module multiple times is virtually free, costing only a
|
---|
| 490 | couple of dictionary lookups. Even if the module name has gone out of scope,
|
---|
| 491 | the module is probably available in :data:`sys.modules`.
|
---|
| 492 |
|
---|
| 493 | If only instances of a specific class use a module, then it is reasonable to
|
---|
| 494 | import the module in the class's ``__init__`` method and then assign the module
|
---|
| 495 | to an instance variable so that the module is always available (via that
|
---|
| 496 | instance variable) during the life of the object. Note that to delay an import
|
---|
| 497 | until the class is instantiated, the import must be inside a method. Putting
|
---|
| 498 | the import inside the class but outside of any method still causes the import to
|
---|
| 499 | occur when the module is initialized.
|
---|
| 500 |
|
---|
| 501 |
|
---|
| 502 | How can I pass optional or keyword parameters from one function to another?
|
---|
| 503 | ---------------------------------------------------------------------------
|
---|
| 504 |
|
---|
| 505 | Collect the arguments using the ``*`` and ``**`` specifiers in the function's
|
---|
| 506 | parameter list; this gives you the positional arguments as a tuple and the
|
---|
| 507 | keyword arguments as a dictionary. You can then pass these arguments when
|
---|
| 508 | calling another function by using ``*`` and ``**``::
|
---|
| 509 |
|
---|
| 510 | def f(x, *args, **kwargs):
|
---|
| 511 | ...
|
---|
| 512 | kwargs['width'] = '14.3c'
|
---|
| 513 | ...
|
---|
| 514 | g(x, *args, **kwargs)
|
---|
| 515 |
|
---|
| 516 | In the unlikely case that you care about Python versions older than 2.0, use
|
---|
| 517 | :func:`apply`::
|
---|
| 518 |
|
---|
| 519 | def f(x, *args, **kwargs):
|
---|
| 520 | ...
|
---|
| 521 | kwargs['width'] = '14.3c'
|
---|
| 522 | ...
|
---|
| 523 | apply(g, (x,)+args, kwargs)
|
---|
| 524 |
|
---|
| 525 |
|
---|
[391] | 526 | .. index::
|
---|
| 527 | single: argument; difference from parameter
|
---|
| 528 | single: parameter; difference from argument
|
---|
| 529 |
|
---|
| 530 | .. _faq-argument-vs-parameter:
|
---|
| 531 |
|
---|
| 532 | What is the difference between arguments and parameters?
|
---|
| 533 | --------------------------------------------------------
|
---|
| 534 |
|
---|
| 535 | :term:`Parameters <parameter>` are defined by the names that appear in a
|
---|
| 536 | function definition, whereas :term:`arguments <argument>` are the values
|
---|
| 537 | actually passed to a function when calling it. Parameters define what types of
|
---|
| 538 | arguments a function can accept. For example, given the function definition::
|
---|
| 539 |
|
---|
| 540 | def func(foo, bar=None, **kwargs):
|
---|
| 541 | pass
|
---|
| 542 |
|
---|
| 543 | *foo*, *bar* and *kwargs* are parameters of ``func``. However, when calling
|
---|
| 544 | ``func``, for example::
|
---|
| 545 |
|
---|
| 546 | func(42, bar=314, extra=somevar)
|
---|
| 547 |
|
---|
| 548 | the values ``42``, ``314``, and ``somevar`` are arguments.
|
---|
| 549 |
|
---|
| 550 |
|
---|
[2] | 551 | How do I write a function with output parameters (call by reference)?
|
---|
| 552 | ---------------------------------------------------------------------
|
---|
| 553 |
|
---|
| 554 | Remember that arguments are passed by assignment in Python. Since assignment
|
---|
| 555 | just creates references to objects, there's no alias between an argument name in
|
---|
| 556 | the caller and callee, and so no call-by-reference per se. You can achieve the
|
---|
| 557 | desired effect in a number of ways.
|
---|
| 558 |
|
---|
| 559 | 1) By returning a tuple of the results::
|
---|
| 560 |
|
---|
| 561 | def func2(a, b):
|
---|
| 562 | a = 'new-value' # a and b are local names
|
---|
| 563 | b = b + 1 # assigned to new objects
|
---|
| 564 | return a, b # return new values
|
---|
| 565 |
|
---|
| 566 | x, y = 'old-value', 99
|
---|
| 567 | x, y = func2(x, y)
|
---|
| 568 | print x, y # output: new-value 100
|
---|
| 569 |
|
---|
| 570 | This is almost always the clearest solution.
|
---|
| 571 |
|
---|
| 572 | 2) By using global variables. This isn't thread-safe, and is not recommended.
|
---|
| 573 |
|
---|
| 574 | 3) By passing a mutable (changeable in-place) object::
|
---|
| 575 |
|
---|
| 576 | def func1(a):
|
---|
| 577 | a[0] = 'new-value' # 'a' references a mutable list
|
---|
| 578 | a[1] = a[1] + 1 # changes a shared object
|
---|
| 579 |
|
---|
| 580 | args = ['old-value', 99]
|
---|
| 581 | func1(args)
|
---|
| 582 | print args[0], args[1] # output: new-value 100
|
---|
| 583 |
|
---|
| 584 | 4) By passing in a dictionary that gets mutated::
|
---|
| 585 |
|
---|
| 586 | def func3(args):
|
---|
| 587 | args['a'] = 'new-value' # args is a mutable dictionary
|
---|
| 588 | args['b'] = args['b'] + 1 # change it in-place
|
---|
| 589 |
|
---|
| 590 | args = {'a':' old-value', 'b': 99}
|
---|
| 591 | func3(args)
|
---|
| 592 | print args['a'], args['b']
|
---|
| 593 |
|
---|
| 594 | 5) Or bundle up values in a class instance::
|
---|
| 595 |
|
---|
| 596 | class callByRef:
|
---|
| 597 | def __init__(self, **args):
|
---|
| 598 | for (key, value) in args.items():
|
---|
| 599 | setattr(self, key, value)
|
---|
| 600 |
|
---|
| 601 | def func4(args):
|
---|
| 602 | args.a = 'new-value' # args is a mutable callByRef
|
---|
| 603 | args.b = args.b + 1 # change object in-place
|
---|
| 604 |
|
---|
| 605 | args = callByRef(a='old-value', b=99)
|
---|
| 606 | func4(args)
|
---|
| 607 | print args.a, args.b
|
---|
| 608 |
|
---|
| 609 |
|
---|
| 610 | There's almost never a good reason to get this complicated.
|
---|
| 611 |
|
---|
| 612 | Your best choice is to return a tuple containing the multiple results.
|
---|
| 613 |
|
---|
| 614 |
|
---|
| 615 | How do you make a higher order function in Python?
|
---|
| 616 | --------------------------------------------------
|
---|
| 617 |
|
---|
| 618 | You have two choices: you can use nested scopes or you can use callable objects.
|
---|
| 619 | For example, suppose you wanted to define ``linear(a,b)`` which returns a
|
---|
| 620 | function ``f(x)`` that computes the value ``a*x+b``. Using nested scopes::
|
---|
| 621 |
|
---|
| 622 | def linear(a, b):
|
---|
| 623 | def result(x):
|
---|
| 624 | return a * x + b
|
---|
| 625 | return result
|
---|
| 626 |
|
---|
| 627 | Or using a callable object::
|
---|
| 628 |
|
---|
| 629 | class linear:
|
---|
| 630 |
|
---|
| 631 | def __init__(self, a, b):
|
---|
| 632 | self.a, self.b = a, b
|
---|
| 633 |
|
---|
| 634 | def __call__(self, x):
|
---|
| 635 | return self.a * x + self.b
|
---|
| 636 |
|
---|
| 637 | In both cases, ::
|
---|
| 638 |
|
---|
| 639 | taxes = linear(0.3, 2)
|
---|
| 640 |
|
---|
| 641 | gives a callable object where ``taxes(10e6) == 0.3 * 10e6 + 2``.
|
---|
| 642 |
|
---|
| 643 | The callable object approach has the disadvantage that it is a bit slower and
|
---|
| 644 | results in slightly longer code. However, note that a collection of callables
|
---|
| 645 | can share their signature via inheritance::
|
---|
| 646 |
|
---|
| 647 | class exponential(linear):
|
---|
| 648 | # __init__ inherited
|
---|
| 649 | def __call__(self, x):
|
---|
| 650 | return self.a * (x ** self.b)
|
---|
| 651 |
|
---|
| 652 | Object can encapsulate state for several methods::
|
---|
| 653 |
|
---|
| 654 | class counter:
|
---|
| 655 |
|
---|
| 656 | value = 0
|
---|
| 657 |
|
---|
| 658 | def set(self, x):
|
---|
| 659 | self.value = x
|
---|
| 660 |
|
---|
| 661 | def up(self):
|
---|
| 662 | self.value = self.value + 1
|
---|
| 663 |
|
---|
| 664 | def down(self):
|
---|
| 665 | self.value = self.value - 1
|
---|
| 666 |
|
---|
| 667 | count = counter()
|
---|
| 668 | inc, dec, reset = count.up, count.down, count.set
|
---|
| 669 |
|
---|
| 670 | Here ``inc()``, ``dec()`` and ``reset()`` act like functions which share the
|
---|
| 671 | same counting variable.
|
---|
| 672 |
|
---|
| 673 |
|
---|
| 674 | How do I copy an object in Python?
|
---|
| 675 | ----------------------------------
|
---|
| 676 |
|
---|
| 677 | In general, try :func:`copy.copy` or :func:`copy.deepcopy` for the general case.
|
---|
| 678 | Not all objects can be copied, but most can.
|
---|
| 679 |
|
---|
| 680 | Some objects can be copied more easily. Dictionaries have a :meth:`~dict.copy`
|
---|
| 681 | method::
|
---|
| 682 |
|
---|
| 683 | newdict = olddict.copy()
|
---|
| 684 |
|
---|
| 685 | Sequences can be copied by slicing::
|
---|
| 686 |
|
---|
| 687 | new_l = l[:]
|
---|
| 688 |
|
---|
| 689 |
|
---|
| 690 | How can I find the methods or attributes of an object?
|
---|
| 691 | ------------------------------------------------------
|
---|
| 692 |
|
---|
| 693 | For an instance x of a user-defined class, ``dir(x)`` returns an alphabetized
|
---|
| 694 | list of the names containing the instance attributes and methods and attributes
|
---|
| 695 | defined by its class.
|
---|
| 696 |
|
---|
| 697 |
|
---|
| 698 | How can my code discover the name of an object?
|
---|
| 699 | -----------------------------------------------
|
---|
| 700 |
|
---|
| 701 | Generally speaking, it can't, because objects don't really have names.
|
---|
| 702 | Essentially, assignment always binds a name to a value; The same is true of
|
---|
| 703 | ``def`` and ``class`` statements, but in that case the value is a
|
---|
| 704 | callable. Consider the following code::
|
---|
| 705 |
|
---|
| 706 | class A:
|
---|
| 707 | pass
|
---|
| 708 |
|
---|
| 709 | B = A
|
---|
| 710 |
|
---|
| 711 | a = B()
|
---|
| 712 | b = a
|
---|
| 713 | print b
|
---|
[391] | 714 | <__main__.A instance at 0x16D07CC>
|
---|
[2] | 715 | print a
|
---|
[391] | 716 | <__main__.A instance at 0x16D07CC>
|
---|
[2] | 717 |
|
---|
| 718 | Arguably the class has a name: even though it is bound to two names and invoked
|
---|
| 719 | through the name B the created instance is still reported as an instance of
|
---|
| 720 | class A. However, it is impossible to say whether the instance's name is a or
|
---|
| 721 | b, since both names are bound to the same value.
|
---|
| 722 |
|
---|
| 723 | Generally speaking it should not be necessary for your code to "know the names"
|
---|
| 724 | of particular values. Unless you are deliberately writing introspective
|
---|
| 725 | programs, this is usually an indication that a change of approach might be
|
---|
| 726 | beneficial.
|
---|
| 727 |
|
---|
| 728 | In comp.lang.python, Fredrik Lundh once gave an excellent analogy in answer to
|
---|
| 729 | this question:
|
---|
| 730 |
|
---|
| 731 | The same way as you get the name of that cat you found on your porch: the cat
|
---|
| 732 | (object) itself cannot tell you its name, and it doesn't really care -- so
|
---|
| 733 | the only way to find out what it's called is to ask all your neighbours
|
---|
| 734 | (namespaces) if it's their cat (object)...
|
---|
| 735 |
|
---|
| 736 | ....and don't be surprised if you'll find that it's known by many names, or
|
---|
| 737 | no name at all!
|
---|
| 738 |
|
---|
| 739 |
|
---|
| 740 | What's up with the comma operator's precedence?
|
---|
| 741 | -----------------------------------------------
|
---|
| 742 |
|
---|
| 743 | Comma is not an operator in Python. Consider this session::
|
---|
| 744 |
|
---|
| 745 | >>> "a" in "b", "a"
|
---|
[391] | 746 | (False, 'a')
|
---|
[2] | 747 |
|
---|
| 748 | Since the comma is not an operator, but a separator between expressions the
|
---|
| 749 | above is evaluated as if you had entered::
|
---|
| 750 |
|
---|
[391] | 751 | ("a" in "b"), "a"
|
---|
[2] | 752 |
|
---|
| 753 | not::
|
---|
| 754 |
|
---|
[391] | 755 | "a" in ("b", "a")
|
---|
[2] | 756 |
|
---|
| 757 | The same is true of the various assignment operators (``=``, ``+=`` etc). They
|
---|
| 758 | are not truly operators but syntactic delimiters in assignment statements.
|
---|
| 759 |
|
---|
| 760 |
|
---|
| 761 | Is there an equivalent of C's "?:" ternary operator?
|
---|
| 762 | ----------------------------------------------------
|
---|
| 763 |
|
---|
| 764 | Yes, this feature was added in Python 2.5. The syntax would be as follows::
|
---|
| 765 |
|
---|
| 766 | [on_true] if [expression] else [on_false]
|
---|
| 767 |
|
---|
| 768 | x, y = 50, 25
|
---|
| 769 |
|
---|
| 770 | small = x if x < y else y
|
---|
| 771 |
|
---|
| 772 | For versions previous to 2.5 the answer would be 'No'.
|
---|
| 773 |
|
---|
| 774 |
|
---|
| 775 | Is it possible to write obfuscated one-liners in Python?
|
---|
| 776 | --------------------------------------------------------
|
---|
| 777 |
|
---|
| 778 | Yes. Usually this is done by nesting :keyword:`lambda` within
|
---|
| 779 | :keyword:`lambda`. See the following three examples, due to Ulf Bartelt::
|
---|
| 780 |
|
---|
| 781 | # Primes < 1000
|
---|
| 782 | print filter(None,map(lambda y:y*reduce(lambda x,y:x*y!=0,
|
---|
| 783 | map(lambda x,y=y:y%x,range(2,int(pow(y,0.5)+1))),1),range(2,1000)))
|
---|
| 784 |
|
---|
| 785 | # First 10 Fibonacci numbers
|
---|
[391] | 786 | print map(lambda x,f=lambda x,f:(f(x-1,f)+f(x-2,f)) if x>1 else 1: f(x,f),
|
---|
[2] | 787 | range(10))
|
---|
| 788 |
|
---|
| 789 | # Mandelbrot set
|
---|
| 790 | print (lambda Ru,Ro,Iu,Io,IM,Sx,Sy:reduce(lambda x,y:x+y,map(lambda y,
|
---|
| 791 | Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,Sy=Sy,L=lambda yc,Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,i=IM,
|
---|
| 792 | Sx=Sx,Sy=Sy:reduce(lambda x,y:x+y,map(lambda x,xc=Ru,yc=yc,Ru=Ru,Ro=Ro,
|
---|
| 793 | 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
|
---|
| 794 | >=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(
|
---|
| 795 | 64+F(Ru+x*(Ro-Ru)/Sx,yc,0,0,i)),range(Sx))):L(Iu+y*(Io-Iu)/Sy),range(Sy
|
---|
| 796 | ))))(-2.1, 0.7, -1.2, 1.2, 30, 80, 24)
|
---|
| 797 | # \___ ___/ \___ ___/ | | |__ lines on screen
|
---|
| 798 | # V V | |______ columns on screen
|
---|
| 799 | # | | |__________ maximum of "iterations"
|
---|
| 800 | # | |_________________ range on y axis
|
---|
| 801 | # |____________________________ range on x axis
|
---|
| 802 |
|
---|
| 803 | Don't try this at home, kids!
|
---|
| 804 |
|
---|
| 805 |
|
---|
| 806 | Numbers and strings
|
---|
| 807 | ===================
|
---|
| 808 |
|
---|
| 809 | How do I specify hexadecimal and octal integers?
|
---|
| 810 | ------------------------------------------------
|
---|
| 811 |
|
---|
[391] | 812 | To specify an octal digit, precede the octal value with a zero, and then a lower
|
---|
| 813 | or uppercase "o". For example, to set the variable "a" to the octal value "10"
|
---|
| 814 | (8 in decimal), type::
|
---|
[2] | 815 |
|
---|
[391] | 816 | >>> a = 0o10
|
---|
[2] | 817 | >>> a
|
---|
| 818 | 8
|
---|
| 819 |
|
---|
| 820 | Hexadecimal is just as easy. Simply precede the hexadecimal number with a zero,
|
---|
| 821 | and then a lower or uppercase "x". Hexadecimal digits can be specified in lower
|
---|
| 822 | or uppercase. For example, in the Python interpreter::
|
---|
| 823 |
|
---|
| 824 | >>> a = 0xa5
|
---|
| 825 | >>> a
|
---|
| 826 | 165
|
---|
| 827 | >>> b = 0XB2
|
---|
| 828 | >>> b
|
---|
| 829 | 178
|
---|
| 830 |
|
---|
| 831 |
|
---|
[391] | 832 | Why does -22 // 10 return -3?
|
---|
| 833 | -----------------------------
|
---|
[2] | 834 |
|
---|
| 835 | It's primarily driven by the desire that ``i % j`` have the same sign as ``j``.
|
---|
| 836 | If you want that, and also want::
|
---|
| 837 |
|
---|
[391] | 838 | i == (i // j) * j + (i % j)
|
---|
[2] | 839 |
|
---|
| 840 | then integer division has to return the floor. C also requires that identity to
|
---|
[391] | 841 | hold, and then compilers that truncate ``i // j`` need to make ``i % j`` have
|
---|
| 842 | the same sign as ``i``.
|
---|
[2] | 843 |
|
---|
| 844 | There are few real use cases for ``i % j`` when ``j`` is negative. When ``j``
|
---|
| 845 | is positive, there are many, and in virtually all of them it's more useful for
|
---|
| 846 | ``i % j`` to be ``>= 0``. If the clock says 10 now, what did it say 200 hours
|
---|
| 847 | ago? ``-190 % 12 == 2`` is useful; ``-190 % 12 == -10`` is a bug waiting to
|
---|
| 848 | bite.
|
---|
| 849 |
|
---|
[391] | 850 | .. note::
|
---|
[2] | 851 |
|
---|
[391] | 852 | On Python 2, ``a / b`` returns the same as ``a // b`` if
|
---|
| 853 | ``__future__.division`` is not in effect. This is also known as "classic"
|
---|
| 854 | division.
|
---|
| 855 |
|
---|
| 856 |
|
---|
[2] | 857 | How do I convert a string to a number?
|
---|
| 858 | --------------------------------------
|
---|
| 859 |
|
---|
| 860 | For integers, use the built-in :func:`int` type constructor, e.g. ``int('144')
|
---|
| 861 | == 144``. Similarly, :func:`float` converts to floating-point,
|
---|
| 862 | e.g. ``float('144') == 144.0``.
|
---|
| 863 |
|
---|
| 864 | By default, these interpret the number as decimal, so that ``int('0144') ==
|
---|
| 865 | 144`` and ``int('0x144')`` raises :exc:`ValueError`. ``int(string, base)`` takes
|
---|
| 866 | the base to convert from as a second optional argument, so ``int('0x144', 16) ==
|
---|
| 867 | 324``. If the base is specified as 0, the number is interpreted using Python's
|
---|
| 868 | rules: a leading '0' indicates octal, and '0x' indicates a hex number.
|
---|
| 869 |
|
---|
| 870 | Do not use the built-in function :func:`eval` if all you need is to convert
|
---|
| 871 | strings to numbers. :func:`eval` will be significantly slower and it presents a
|
---|
| 872 | security risk: someone could pass you a Python expression that might have
|
---|
| 873 | unwanted side effects. For example, someone could pass
|
---|
| 874 | ``__import__('os').system("rm -rf $HOME")`` which would erase your home
|
---|
| 875 | directory.
|
---|
| 876 |
|
---|
| 877 | :func:`eval` also has the effect of interpreting numbers as Python expressions,
|
---|
| 878 | so that e.g. ``eval('09')`` gives a syntax error because Python regards numbers
|
---|
| 879 | starting with '0' as octal (base 8).
|
---|
| 880 |
|
---|
| 881 |
|
---|
| 882 | How do I convert a number to a string?
|
---|
| 883 | --------------------------------------
|
---|
| 884 |
|
---|
| 885 | To convert, e.g., the number 144 to the string '144', use the built-in type
|
---|
| 886 | constructor :func:`str`. If you want a hexadecimal or octal representation, use
|
---|
[391] | 887 | the built-in functions :func:`hex` or :func:`oct`. For fancy formatting, see
|
---|
| 888 | the :ref:`formatstrings` section, e.g. ``"{:04d}".format(144)`` yields
|
---|
| 889 | ``'0144'`` and ``"{:.3f}".format(1/3)`` yields ``'0.333'``. You may also use
|
---|
| 890 | :ref:`the % operator <string-formatting>` on strings. See the library reference
|
---|
| 891 | manual for details.
|
---|
[2] | 892 |
|
---|
| 893 |
|
---|
| 894 | How do I modify a string in place?
|
---|
| 895 | ----------------------------------
|
---|
| 896 |
|
---|
| 897 | You can't, because strings are immutable. If you need an object with this
|
---|
| 898 | ability, try converting the string to a list or use the array module::
|
---|
| 899 |
|
---|
[391] | 900 | >>> import io
|
---|
[2] | 901 | >>> s = "Hello, world"
|
---|
| 902 | >>> a = list(s)
|
---|
| 903 | >>> print a
|
---|
| 904 | ['H', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r', 'l', 'd']
|
---|
| 905 | >>> a[7:] = list("there!")
|
---|
| 906 | >>> ''.join(a)
|
---|
| 907 | 'Hello, there!'
|
---|
| 908 |
|
---|
| 909 | >>> import array
|
---|
| 910 | >>> a = array.array('c', s)
|
---|
| 911 | >>> print a
|
---|
| 912 | array('c', 'Hello, world')
|
---|
| 913 | >>> a[0] = 'y' ; print a
|
---|
[391] | 914 | array('c', 'yello, world')
|
---|
[2] | 915 | >>> a.tostring()
|
---|
| 916 | 'yello, world'
|
---|
| 917 |
|
---|
| 918 |
|
---|
| 919 | How do I use strings to call functions/methods?
|
---|
| 920 | -----------------------------------------------
|
---|
| 921 |
|
---|
| 922 | There are various techniques.
|
---|
| 923 |
|
---|
| 924 | * The best is to use a dictionary that maps strings to functions. The primary
|
---|
| 925 | advantage of this technique is that the strings do not need to match the names
|
---|
| 926 | of the functions. This is also the primary technique used to emulate a case
|
---|
| 927 | construct::
|
---|
| 928 |
|
---|
| 929 | def a():
|
---|
| 930 | pass
|
---|
| 931 |
|
---|
| 932 | def b():
|
---|
| 933 | pass
|
---|
| 934 |
|
---|
| 935 | dispatch = {'go': a, 'stop': b} # Note lack of parens for funcs
|
---|
| 936 |
|
---|
| 937 | dispatch[get_input()]() # Note trailing parens to call function
|
---|
| 938 |
|
---|
| 939 | * Use the built-in function :func:`getattr`::
|
---|
| 940 |
|
---|
| 941 | import foo
|
---|
| 942 | getattr(foo, 'bar')()
|
---|
| 943 |
|
---|
| 944 | Note that :func:`getattr` works on any object, including classes, class
|
---|
| 945 | instances, modules, and so on.
|
---|
| 946 |
|
---|
| 947 | This is used in several places in the standard library, like this::
|
---|
| 948 |
|
---|
| 949 | class Foo:
|
---|
| 950 | def do_foo(self):
|
---|
| 951 | ...
|
---|
| 952 |
|
---|
| 953 | def do_bar(self):
|
---|
| 954 | ...
|
---|
| 955 |
|
---|
| 956 | f = getattr(foo_instance, 'do_' + opname)
|
---|
| 957 | f()
|
---|
| 958 |
|
---|
| 959 |
|
---|
| 960 | * Use :func:`locals` or :func:`eval` to resolve the function name::
|
---|
| 961 |
|
---|
| 962 | def myFunc():
|
---|
| 963 | print "hello"
|
---|
| 964 |
|
---|
| 965 | fname = "myFunc"
|
---|
| 966 |
|
---|
| 967 | f = locals()[fname]
|
---|
| 968 | f()
|
---|
| 969 |
|
---|
| 970 | f = eval(fname)
|
---|
| 971 | f()
|
---|
| 972 |
|
---|
| 973 | Note: Using :func:`eval` is slow and dangerous. If you don't have absolute
|
---|
| 974 | control over the contents of the string, someone could pass a string that
|
---|
| 975 | resulted in an arbitrary function being executed.
|
---|
| 976 |
|
---|
| 977 | Is there an equivalent to Perl's chomp() for removing trailing newlines from strings?
|
---|
| 978 | -------------------------------------------------------------------------------------
|
---|
| 979 |
|
---|
| 980 | Starting with Python 2.2, you can use ``S.rstrip("\r\n")`` to remove all
|
---|
[391] | 981 | occurrences of any line terminator from the end of the string ``S`` without
|
---|
[2] | 982 | removing other trailing whitespace. If the string ``S`` represents more than
|
---|
| 983 | one line, with several empty lines at the end, the line terminators for all the
|
---|
| 984 | blank lines will be removed::
|
---|
| 985 |
|
---|
| 986 | >>> lines = ("line 1 \r\n"
|
---|
| 987 | ... "\r\n"
|
---|
| 988 | ... "\r\n")
|
---|
| 989 | >>> lines.rstrip("\n\r")
|
---|
[391] | 990 | 'line 1 '
|
---|
[2] | 991 |
|
---|
| 992 | Since this is typically only desired when reading text one line at a time, using
|
---|
| 993 | ``S.rstrip()`` this way works well.
|
---|
| 994 |
|
---|
[391] | 995 | For older versions of Python, there are two partial substitutes:
|
---|
[2] | 996 |
|
---|
| 997 | - If you want to remove all trailing whitespace, use the ``rstrip()`` method of
|
---|
| 998 | string objects. This removes all trailing whitespace, not just a single
|
---|
| 999 | newline.
|
---|
| 1000 |
|
---|
| 1001 | - Otherwise, if there is only one line in the string ``S``, use
|
---|
| 1002 | ``S.splitlines()[0]``.
|
---|
| 1003 |
|
---|
| 1004 |
|
---|
| 1005 | Is there a scanf() or sscanf() equivalent?
|
---|
| 1006 | ------------------------------------------
|
---|
| 1007 |
|
---|
| 1008 | Not as such.
|
---|
| 1009 |
|
---|
| 1010 | For simple input parsing, the easiest approach is usually to split the line into
|
---|
| 1011 | whitespace-delimited words using the :meth:`~str.split` method of string objects
|
---|
| 1012 | and then convert decimal strings to numeric values using :func:`int` or
|
---|
| 1013 | :func:`float`. ``split()`` supports an optional "sep" parameter which is useful
|
---|
| 1014 | if the line uses something other than whitespace as a separator.
|
---|
| 1015 |
|
---|
[391] | 1016 | For more complicated input parsing, regular expressions are more powerful
|
---|
| 1017 | than C's :c:func:`sscanf` and better suited for the task.
|
---|
[2] | 1018 |
|
---|
| 1019 |
|
---|
| 1020 | What does 'UnicodeError: ASCII [decoding,encoding] error: ordinal not in range(128)' mean?
|
---|
| 1021 | ------------------------------------------------------------------------------------------
|
---|
| 1022 |
|
---|
| 1023 | This error indicates that your Python installation can handle only 7-bit ASCII
|
---|
| 1024 | strings. There are a couple ways to fix or work around the problem.
|
---|
| 1025 |
|
---|
| 1026 | If your programs must handle data in arbitrary character set encodings, the
|
---|
| 1027 | environment the application runs in will generally identify the encoding of the
|
---|
| 1028 | data it is handing you. You need to convert the input to Unicode data using
|
---|
| 1029 | that encoding. For example, a program that handles email or web input will
|
---|
| 1030 | typically find character set encoding information in Content-Type headers. This
|
---|
| 1031 | can then be used to properly convert input data to Unicode. Assuming the string
|
---|
| 1032 | referred to by ``value`` is encoded as UTF-8::
|
---|
| 1033 |
|
---|
| 1034 | value = unicode(value, "utf-8")
|
---|
| 1035 |
|
---|
| 1036 | will return a Unicode object. If the data is not correctly encoded as UTF-8,
|
---|
| 1037 | the above call will raise a :exc:`UnicodeError` exception.
|
---|
| 1038 |
|
---|
| 1039 | If you only want strings converted to Unicode which have non-ASCII data, you can
|
---|
| 1040 | try converting them first assuming an ASCII encoding, and then generate Unicode
|
---|
| 1041 | objects if that fails::
|
---|
| 1042 |
|
---|
| 1043 | try:
|
---|
| 1044 | x = unicode(value, "ascii")
|
---|
| 1045 | except UnicodeError:
|
---|
| 1046 | value = unicode(value, "utf-8")
|
---|
| 1047 | else:
|
---|
| 1048 | # value was valid ASCII data
|
---|
| 1049 | pass
|
---|
| 1050 |
|
---|
| 1051 | It's possible to set a default encoding in a file called ``sitecustomize.py``
|
---|
| 1052 | that's part of the Python library. However, this isn't recommended because
|
---|
| 1053 | changing the Python-wide default encoding may cause third-party extension
|
---|
| 1054 | modules to fail.
|
---|
| 1055 |
|
---|
| 1056 | Note that on Windows, there is an encoding known as "mbcs", which uses an
|
---|
| 1057 | encoding specific to your current locale. In many cases, and particularly when
|
---|
| 1058 | working with COM, this may be an appropriate default encoding to use.
|
---|
| 1059 |
|
---|
| 1060 |
|
---|
| 1061 | Sequences (Tuples/Lists)
|
---|
| 1062 | ========================
|
---|
| 1063 |
|
---|
| 1064 | How do I convert between tuples and lists?
|
---|
| 1065 | ------------------------------------------
|
---|
| 1066 |
|
---|
| 1067 | The type constructor ``tuple(seq)`` converts any sequence (actually, any
|
---|
| 1068 | iterable) into a tuple with the same items in the same order.
|
---|
| 1069 |
|
---|
| 1070 | For example, ``tuple([1, 2, 3])`` yields ``(1, 2, 3)`` and ``tuple('abc')``
|
---|
| 1071 | yields ``('a', 'b', 'c')``. If the argument is a tuple, it does not make a copy
|
---|
| 1072 | but returns the same object, so it is cheap to call :func:`tuple` when you
|
---|
| 1073 | aren't sure that an object is already a tuple.
|
---|
| 1074 |
|
---|
| 1075 | The type constructor ``list(seq)`` converts any sequence or iterable into a list
|
---|
| 1076 | with the same items in the same order. For example, ``list((1, 2, 3))`` yields
|
---|
| 1077 | ``[1, 2, 3]`` and ``list('abc')`` yields ``['a', 'b', 'c']``. If the argument
|
---|
| 1078 | is a list, it makes a copy just like ``seq[:]`` would.
|
---|
| 1079 |
|
---|
| 1080 |
|
---|
| 1081 | What's a negative index?
|
---|
| 1082 | ------------------------
|
---|
| 1083 |
|
---|
| 1084 | Python sequences are indexed with positive numbers and negative numbers. For
|
---|
| 1085 | positive numbers 0 is the first index 1 is the second index and so forth. For
|
---|
| 1086 | negative indices -1 is the last index and -2 is the penultimate (next to last)
|
---|
| 1087 | index and so forth. Think of ``seq[-n]`` as the same as ``seq[len(seq)-n]``.
|
---|
| 1088 |
|
---|
| 1089 | Using negative indices can be very convenient. For example ``S[:-1]`` is all of
|
---|
| 1090 | the string except for its last character, which is useful for removing the
|
---|
| 1091 | trailing newline from a string.
|
---|
| 1092 |
|
---|
| 1093 |
|
---|
| 1094 | How do I iterate over a sequence in reverse order?
|
---|
| 1095 | --------------------------------------------------
|
---|
| 1096 |
|
---|
| 1097 | Use the :func:`reversed` built-in function, which is new in Python 2.4::
|
---|
| 1098 |
|
---|
| 1099 | for x in reversed(sequence):
|
---|
| 1100 | ... # do something with x...
|
---|
| 1101 |
|
---|
| 1102 | This won't touch your original sequence, but build a new copy with reversed
|
---|
| 1103 | order to iterate over.
|
---|
| 1104 |
|
---|
| 1105 | With Python 2.3, you can use an extended slice syntax::
|
---|
| 1106 |
|
---|
| 1107 | for x in sequence[::-1]:
|
---|
| 1108 | ... # do something with x...
|
---|
| 1109 |
|
---|
| 1110 |
|
---|
| 1111 | How do you remove duplicates from a list?
|
---|
| 1112 | -----------------------------------------
|
---|
| 1113 |
|
---|
| 1114 | See the Python Cookbook for a long discussion of many ways to do this:
|
---|
| 1115 |
|
---|
| 1116 | http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52560
|
---|
| 1117 |
|
---|
| 1118 | If you don't mind reordering the list, sort it and then scan from the end of the
|
---|
| 1119 | list, deleting duplicates as you go::
|
---|
| 1120 |
|
---|
[391] | 1121 | if mylist:
|
---|
| 1122 | mylist.sort()
|
---|
| 1123 | last = mylist[-1]
|
---|
| 1124 | for i in range(len(mylist)-2, -1, -1):
|
---|
| 1125 | if last == mylist[i]:
|
---|
| 1126 | del mylist[i]
|
---|
[2] | 1127 | else:
|
---|
[391] | 1128 | last = mylist[i]
|
---|
[2] | 1129 |
|
---|
| 1130 | If all elements of the list may be used as dictionary keys (i.e. they are all
|
---|
| 1131 | hashable) this is often faster ::
|
---|
| 1132 |
|
---|
| 1133 | d = {}
|
---|
[391] | 1134 | for x in mylist:
|
---|
| 1135 | d[x] = 1
|
---|
| 1136 | mylist = list(d.keys())
|
---|
[2] | 1137 |
|
---|
| 1138 | In Python 2.5 and later, the following is possible instead::
|
---|
| 1139 |
|
---|
[391] | 1140 | mylist = list(set(mylist))
|
---|
[2] | 1141 |
|
---|
| 1142 | This converts the list into a set, thereby removing duplicates, and then back
|
---|
| 1143 | into a list.
|
---|
| 1144 |
|
---|
| 1145 |
|
---|
| 1146 | How do you make an array in Python?
|
---|
| 1147 | -----------------------------------
|
---|
| 1148 |
|
---|
| 1149 | Use a list::
|
---|
| 1150 |
|
---|
| 1151 | ["this", 1, "is", "an", "array"]
|
---|
| 1152 |
|
---|
| 1153 | Lists are equivalent to C or Pascal arrays in their time complexity; the primary
|
---|
| 1154 | difference is that a Python list can contain objects of many different types.
|
---|
| 1155 |
|
---|
| 1156 | The ``array`` module also provides methods for creating arrays of fixed types
|
---|
| 1157 | with compact representations, but they are slower to index than lists. Also
|
---|
| 1158 | note that the Numeric extensions and others define array-like structures with
|
---|
| 1159 | various characteristics as well.
|
---|
| 1160 |
|
---|
| 1161 | To get Lisp-style linked lists, you can emulate cons cells using tuples::
|
---|
| 1162 |
|
---|
| 1163 | lisp_list = ("like", ("this", ("example", None) ) )
|
---|
| 1164 |
|
---|
| 1165 | If mutability is desired, you could use lists instead of tuples. Here the
|
---|
| 1166 | analogue of lisp car is ``lisp_list[0]`` and the analogue of cdr is
|
---|
| 1167 | ``lisp_list[1]``. Only do this if you're sure you really need to, because it's
|
---|
| 1168 | usually a lot slower than using Python lists.
|
---|
| 1169 |
|
---|
| 1170 |
|
---|
| 1171 | How do I create a multidimensional list?
|
---|
| 1172 | ----------------------------------------
|
---|
| 1173 |
|
---|
| 1174 | You probably tried to make a multidimensional array like this::
|
---|
| 1175 |
|
---|
[391] | 1176 | >>> A = [[None] * 2] * 3
|
---|
[2] | 1177 |
|
---|
| 1178 | This looks correct if you print it::
|
---|
| 1179 |
|
---|
| 1180 | >>> A
|
---|
| 1181 | [[None, None], [None, None], [None, None]]
|
---|
| 1182 |
|
---|
| 1183 | But when you assign a value, it shows up in multiple places:
|
---|
| 1184 |
|
---|
| 1185 | >>> A[0][0] = 5
|
---|
| 1186 | >>> A
|
---|
| 1187 | [[5, None], [5, None], [5, None]]
|
---|
| 1188 |
|
---|
| 1189 | The reason is that replicating a list with ``*`` doesn't create copies, it only
|
---|
| 1190 | creates references to the existing objects. The ``*3`` creates a list
|
---|
| 1191 | containing 3 references to the same list of length two. Changes to one row will
|
---|
| 1192 | show in all rows, which is almost certainly not what you want.
|
---|
| 1193 |
|
---|
| 1194 | The suggested approach is to create a list of the desired length first and then
|
---|
| 1195 | fill in each element with a newly created list::
|
---|
| 1196 |
|
---|
| 1197 | A = [None] * 3
|
---|
| 1198 | for i in range(3):
|
---|
| 1199 | A[i] = [None] * 2
|
---|
| 1200 |
|
---|
| 1201 | This generates a list containing 3 different lists of length two. You can also
|
---|
| 1202 | use a list comprehension::
|
---|
| 1203 |
|
---|
| 1204 | w, h = 2, 3
|
---|
| 1205 | A = [[None] * w for i in range(h)]
|
---|
| 1206 |
|
---|
| 1207 | Or, you can use an extension that provides a matrix datatype; `Numeric Python
|
---|
[391] | 1208 | <http://www.numpy.org/>`_ is the best known.
|
---|
[2] | 1209 |
|
---|
| 1210 |
|
---|
| 1211 | How do I apply a method to a sequence of objects?
|
---|
| 1212 | -------------------------------------------------
|
---|
| 1213 |
|
---|
| 1214 | Use a list comprehension::
|
---|
| 1215 |
|
---|
[391] | 1216 | result = [obj.method() for obj in mylist]
|
---|
[2] | 1217 |
|
---|
| 1218 | More generically, you can try the following function::
|
---|
| 1219 |
|
---|
| 1220 | def method_map(objects, method, arguments):
|
---|
| 1221 | """method_map([a,b], "meth", (1,2)) gives [a.meth(1,2), b.meth(1,2)]"""
|
---|
| 1222 | nobjects = len(objects)
|
---|
| 1223 | methods = map(getattr, objects, [method]*nobjects)
|
---|
| 1224 | return map(apply, methods, [arguments]*nobjects)
|
---|
| 1225 |
|
---|
| 1226 |
|
---|
[391] | 1227 | Why does a_tuple[i] += ['item'] raise an exception when the addition works?
|
---|
| 1228 | ---------------------------------------------------------------------------
|
---|
| 1229 |
|
---|
| 1230 | This is because of a combination of the fact that augmented assignment
|
---|
| 1231 | operators are *assignment* operators, and the difference between mutable and
|
---|
| 1232 | immutable objects in Python.
|
---|
| 1233 |
|
---|
| 1234 | This discussion applies in general when augmented assignment operators are
|
---|
| 1235 | applied to elements of a tuple that point to mutable objects, but we'll use
|
---|
| 1236 | a ``list`` and ``+=`` as our exemplar.
|
---|
| 1237 |
|
---|
| 1238 | If you wrote::
|
---|
| 1239 |
|
---|
| 1240 | >>> a_tuple = (1, 2)
|
---|
| 1241 | >>> a_tuple[0] += 1
|
---|
| 1242 | Traceback (most recent call last):
|
---|
| 1243 | ...
|
---|
| 1244 | TypeError: 'tuple' object does not support item assignment
|
---|
| 1245 |
|
---|
| 1246 | The reason for the exception should be immediately clear: ``1`` is added to the
|
---|
| 1247 | object ``a_tuple[0]`` points to (``1``), producing the result object, ``2``,
|
---|
| 1248 | but when we attempt to assign the result of the computation, ``2``, to element
|
---|
| 1249 | ``0`` of the tuple, we get an error because we can't change what an element of
|
---|
| 1250 | a tuple points to.
|
---|
| 1251 |
|
---|
| 1252 | Under the covers, what this augmented assignment statement is doing is
|
---|
| 1253 | approximately this::
|
---|
| 1254 |
|
---|
| 1255 | >>> result = a_tuple[0] + 1
|
---|
| 1256 | >>> a_tuple[0] = result
|
---|
| 1257 | Traceback (most recent call last):
|
---|
| 1258 | ...
|
---|
| 1259 | TypeError: 'tuple' object does not support item assignment
|
---|
| 1260 |
|
---|
| 1261 | It is the assignment part of the operation that produces the error, since a
|
---|
| 1262 | tuple is immutable.
|
---|
| 1263 |
|
---|
| 1264 | When you write something like::
|
---|
| 1265 |
|
---|
| 1266 | >>> a_tuple = (['foo'], 'bar')
|
---|
| 1267 | >>> a_tuple[0] += ['item']
|
---|
| 1268 | Traceback (most recent call last):
|
---|
| 1269 | ...
|
---|
| 1270 | TypeError: 'tuple' object does not support item assignment
|
---|
| 1271 |
|
---|
| 1272 | The exception is a bit more surprising, and even more surprising is the fact
|
---|
| 1273 | that even though there was an error, the append worked::
|
---|
| 1274 |
|
---|
| 1275 | >>> a_tuple[0]
|
---|
| 1276 | ['foo', 'item']
|
---|
| 1277 |
|
---|
| 1278 | To see why this happens, you need to know that (a) if an object implements an
|
---|
| 1279 | ``__iadd__`` magic method, it gets called when the ``+=`` augmented assignment
|
---|
| 1280 | is executed, and its return value is what gets used in the assignment statement;
|
---|
| 1281 | and (b) for lists, ``__iadd__`` is equivalent to calling ``extend`` on the list
|
---|
| 1282 | and returning the list. That's why we say that for lists, ``+=`` is a
|
---|
| 1283 | "shorthand" for ``list.extend``::
|
---|
| 1284 |
|
---|
| 1285 | >>> a_list = []
|
---|
| 1286 | >>> a_list += [1]
|
---|
| 1287 | >>> a_list
|
---|
| 1288 | [1]
|
---|
| 1289 |
|
---|
| 1290 | This is equivalent to::
|
---|
| 1291 |
|
---|
| 1292 | >>> result = a_list.__iadd__([1])
|
---|
| 1293 | >>> a_list = result
|
---|
| 1294 |
|
---|
| 1295 | The object pointed to by a_list has been mutated, and the pointer to the
|
---|
| 1296 | mutated object is assigned back to ``a_list``. The end result of the
|
---|
| 1297 | assignment is a no-op, since it is a pointer to the same object that ``a_list``
|
---|
| 1298 | was previously pointing to, but the assignment still happens.
|
---|
| 1299 |
|
---|
| 1300 | Thus, in our tuple example what is happening is equivalent to::
|
---|
| 1301 |
|
---|
| 1302 | >>> result = a_tuple[0].__iadd__(['item'])
|
---|
| 1303 | >>> a_tuple[0] = result
|
---|
| 1304 | Traceback (most recent call last):
|
---|
| 1305 | ...
|
---|
| 1306 | TypeError: 'tuple' object does not support item assignment
|
---|
| 1307 |
|
---|
| 1308 | The ``__iadd__`` succeeds, and thus the list is extended, but even though
|
---|
| 1309 | ``result`` points to the same object that ``a_tuple[0]`` already points to,
|
---|
| 1310 | that final assignment still results in an error, because tuples are immutable.
|
---|
| 1311 |
|
---|
| 1312 |
|
---|
[2] | 1313 | Dictionaries
|
---|
| 1314 | ============
|
---|
| 1315 |
|
---|
| 1316 | How can I get a dictionary to display its keys in a consistent order?
|
---|
| 1317 | ---------------------------------------------------------------------
|
---|
| 1318 |
|
---|
| 1319 | You can't. Dictionaries store their keys in an unpredictable order, so the
|
---|
| 1320 | display order of a dictionary's elements will be similarly unpredictable.
|
---|
| 1321 |
|
---|
| 1322 | This can be frustrating if you want to save a printable version to a file, make
|
---|
| 1323 | some changes and then compare it with some other printed dictionary. In this
|
---|
| 1324 | case, use the ``pprint`` module to pretty-print the dictionary; the items will
|
---|
| 1325 | be presented in order sorted by the key.
|
---|
| 1326 |
|
---|
[391] | 1327 | A more complicated solution is to subclass ``dict`` to create a
|
---|
[2] | 1328 | ``SortedDict`` class that prints itself in a predictable order. Here's one
|
---|
| 1329 | simpleminded implementation of such a class::
|
---|
| 1330 |
|
---|
[391] | 1331 | class SortedDict(dict):
|
---|
[2] | 1332 | def __repr__(self):
|
---|
[391] | 1333 | keys = sorted(self.keys())
|
---|
| 1334 | result = ("{!r}: {!r}".format(k, self[k]) for k in keys)
|
---|
| 1335 | return "{{{}}}".format(", ".join(result))
|
---|
[2] | 1336 |
|
---|
[391] | 1337 | __str__ = __repr__
|
---|
[2] | 1338 |
|
---|
| 1339 | This will work for many common situations you might encounter, though it's far
|
---|
| 1340 | from a perfect solution. The largest flaw is that if some values in the
|
---|
| 1341 | dictionary are also dictionaries, their values won't be presented in any
|
---|
| 1342 | particular order.
|
---|
| 1343 |
|
---|
| 1344 |
|
---|
| 1345 | I want to do a complicated sort: can you do a Schwartzian Transform in Python?
|
---|
| 1346 | ------------------------------------------------------------------------------
|
---|
| 1347 |
|
---|
| 1348 | The technique, attributed to Randal Schwartz of the Perl community, sorts the
|
---|
| 1349 | elements of a list by a metric which maps each element to its "sort value". In
|
---|
| 1350 | Python, just use the ``key`` argument for the ``sort()`` method::
|
---|
| 1351 |
|
---|
| 1352 | Isorted = L[:]
|
---|
| 1353 | Isorted.sort(key=lambda s: int(s[10:15]))
|
---|
| 1354 |
|
---|
| 1355 | The ``key`` argument is new in Python 2.4, for older versions this kind of
|
---|
| 1356 | sorting is quite simple to do with list comprehensions. To sort a list of
|
---|
| 1357 | strings by their uppercase values::
|
---|
| 1358 |
|
---|
[391] | 1359 | tmp1 = [(x.upper(), x) for x in L] # Schwartzian transform
|
---|
[2] | 1360 | tmp1.sort()
|
---|
| 1361 | Usorted = [x[1] for x in tmp1]
|
---|
| 1362 |
|
---|
| 1363 | To sort by the integer value of a subfield extending from positions 10-15 in
|
---|
| 1364 | each string::
|
---|
| 1365 |
|
---|
[391] | 1366 | tmp2 = [(int(s[10:15]), s) for s in L] # Schwartzian transform
|
---|
[2] | 1367 | tmp2.sort()
|
---|
| 1368 | Isorted = [x[1] for x in tmp2]
|
---|
| 1369 |
|
---|
| 1370 | Note that Isorted may also be computed by ::
|
---|
| 1371 |
|
---|
| 1372 | def intfield(s):
|
---|
| 1373 | return int(s[10:15])
|
---|
| 1374 |
|
---|
| 1375 | def Icmp(s1, s2):
|
---|
| 1376 | return cmp(intfield(s1), intfield(s2))
|
---|
| 1377 |
|
---|
| 1378 | Isorted = L[:]
|
---|
| 1379 | Isorted.sort(Icmp)
|
---|
| 1380 |
|
---|
| 1381 | but since this method calls ``intfield()`` many times for each element of L, it
|
---|
| 1382 | is slower than the Schwartzian Transform.
|
---|
| 1383 |
|
---|
| 1384 |
|
---|
| 1385 | How can I sort one list by values from another list?
|
---|
| 1386 | ----------------------------------------------------
|
---|
| 1387 |
|
---|
| 1388 | Merge them into a single list of tuples, sort the resulting list, and then pick
|
---|
| 1389 | out the element you want. ::
|
---|
| 1390 |
|
---|
| 1391 | >>> list1 = ["what", "I'm", "sorting", "by"]
|
---|
| 1392 | >>> list2 = ["something", "else", "to", "sort"]
|
---|
| 1393 | >>> pairs = zip(list1, list2)
|
---|
| 1394 | >>> pairs
|
---|
| 1395 | [('what', 'something'), ("I'm", 'else'), ('sorting', 'to'), ('by', 'sort')]
|
---|
| 1396 | >>> pairs.sort()
|
---|
| 1397 | >>> result = [ x[1] for x in pairs ]
|
---|
| 1398 | >>> result
|
---|
| 1399 | ['else', 'sort', 'to', 'something']
|
---|
| 1400 |
|
---|
| 1401 | An alternative for the last step is::
|
---|
| 1402 |
|
---|
[391] | 1403 | >>> result = []
|
---|
| 1404 | >>> for p in pairs: result.append(p[1])
|
---|
[2] | 1405 |
|
---|
| 1406 | If you find this more legible, you might prefer to use this instead of the final
|
---|
| 1407 | list comprehension. However, it is almost twice as slow for long lists. Why?
|
---|
| 1408 | First, the ``append()`` operation has to reallocate memory, and while it uses
|
---|
| 1409 | some tricks to avoid doing that each time, it still has to do it occasionally,
|
---|
| 1410 | and that costs quite a bit. Second, the expression "result.append" requires an
|
---|
| 1411 | extra attribute lookup, and third, there's a speed reduction from having to make
|
---|
| 1412 | all those function calls.
|
---|
| 1413 |
|
---|
| 1414 |
|
---|
| 1415 | Objects
|
---|
| 1416 | =======
|
---|
| 1417 |
|
---|
| 1418 | What is a class?
|
---|
| 1419 | ----------------
|
---|
| 1420 |
|
---|
| 1421 | A class is the particular object type created by executing a class statement.
|
---|
| 1422 | Class objects are used as templates to create instance objects, which embody
|
---|
| 1423 | both the data (attributes) and code (methods) specific to a datatype.
|
---|
| 1424 |
|
---|
| 1425 | A class can be based on one or more other classes, called its base class(es). It
|
---|
| 1426 | then inherits the attributes and methods of its base classes. This allows an
|
---|
| 1427 | object model to be successively refined by inheritance. You might have a
|
---|
| 1428 | generic ``Mailbox`` class that provides basic accessor methods for a mailbox,
|
---|
| 1429 | and subclasses such as ``MboxMailbox``, ``MaildirMailbox``, ``OutlookMailbox``
|
---|
| 1430 | that handle various specific mailbox formats.
|
---|
| 1431 |
|
---|
| 1432 |
|
---|
| 1433 | What is a method?
|
---|
| 1434 | -----------------
|
---|
| 1435 |
|
---|
| 1436 | A method is a function on some object ``x`` that you normally call as
|
---|
| 1437 | ``x.name(arguments...)``. Methods are defined as functions inside the class
|
---|
| 1438 | definition::
|
---|
| 1439 |
|
---|
| 1440 | class C:
|
---|
| 1441 | def meth (self, arg):
|
---|
| 1442 | return arg * 2 + self.attribute
|
---|
| 1443 |
|
---|
| 1444 |
|
---|
| 1445 | What is self?
|
---|
| 1446 | -------------
|
---|
| 1447 |
|
---|
| 1448 | Self is merely a conventional name for the first argument of a method. A method
|
---|
| 1449 | defined as ``meth(self, a, b, c)`` should be called as ``x.meth(a, b, c)`` for
|
---|
| 1450 | some instance ``x`` of the class in which the definition occurs; the called
|
---|
| 1451 | method will think it is called as ``meth(x, a, b, c)``.
|
---|
| 1452 |
|
---|
| 1453 | See also :ref:`why-self`.
|
---|
| 1454 |
|
---|
| 1455 |
|
---|
| 1456 | How do I check if an object is an instance of a given class or of a subclass of it?
|
---|
| 1457 | -----------------------------------------------------------------------------------
|
---|
| 1458 |
|
---|
| 1459 | Use the built-in function ``isinstance(obj, cls)``. You can check if an object
|
---|
| 1460 | is an instance of any of a number of classes by providing a tuple instead of a
|
---|
| 1461 | single class, e.g. ``isinstance(obj, (class1, class2, ...))``, and can also
|
---|
| 1462 | check whether an object is one of Python's built-in types, e.g.
|
---|
| 1463 | ``isinstance(obj, str)`` or ``isinstance(obj, (int, long, float, complex))``.
|
---|
| 1464 |
|
---|
| 1465 | Note that most programs do not use :func:`isinstance` on user-defined classes
|
---|
| 1466 | very often. If you are developing the classes yourself, a more proper
|
---|
| 1467 | object-oriented style is to define methods on the classes that encapsulate a
|
---|
| 1468 | particular behaviour, instead of checking the object's class and doing a
|
---|
| 1469 | different thing based on what class it is. For example, if you have a function
|
---|
| 1470 | that does something::
|
---|
| 1471 |
|
---|
[391] | 1472 | def search(obj):
|
---|
[2] | 1473 | if isinstance(obj, Mailbox):
|
---|
| 1474 | # ... code to search a mailbox
|
---|
| 1475 | elif isinstance(obj, Document):
|
---|
| 1476 | # ... code to search a document
|
---|
| 1477 | elif ...
|
---|
| 1478 |
|
---|
| 1479 | A better approach is to define a ``search()`` method on all the classes and just
|
---|
| 1480 | call it::
|
---|
| 1481 |
|
---|
| 1482 | class Mailbox:
|
---|
| 1483 | def search(self):
|
---|
| 1484 | # ... code to search a mailbox
|
---|
| 1485 |
|
---|
| 1486 | class Document:
|
---|
| 1487 | def search(self):
|
---|
| 1488 | # ... code to search a document
|
---|
| 1489 |
|
---|
| 1490 | obj.search()
|
---|
| 1491 |
|
---|
| 1492 |
|
---|
| 1493 | What is delegation?
|
---|
| 1494 | -------------------
|
---|
| 1495 |
|
---|
| 1496 | Delegation is an object oriented technique (also called a design pattern).
|
---|
| 1497 | Let's say you have an object ``x`` and want to change the behaviour of just one
|
---|
| 1498 | of its methods. You can create a new class that provides a new implementation
|
---|
| 1499 | of the method you're interested in changing and delegates all other methods to
|
---|
| 1500 | the corresponding method of ``x``.
|
---|
| 1501 |
|
---|
| 1502 | Python programmers can easily implement delegation. For example, the following
|
---|
| 1503 | class implements a class that behaves like a file but converts all written data
|
---|
| 1504 | to uppercase::
|
---|
| 1505 |
|
---|
| 1506 | class UpperOut:
|
---|
| 1507 |
|
---|
| 1508 | def __init__(self, outfile):
|
---|
| 1509 | self._outfile = outfile
|
---|
| 1510 |
|
---|
| 1511 | def write(self, s):
|
---|
| 1512 | self._outfile.write(s.upper())
|
---|
| 1513 |
|
---|
| 1514 | def __getattr__(self, name):
|
---|
| 1515 | return getattr(self._outfile, name)
|
---|
| 1516 |
|
---|
| 1517 | Here the ``UpperOut`` class redefines the ``write()`` method to convert the
|
---|
| 1518 | argument string to uppercase before calling the underlying
|
---|
| 1519 | ``self.__outfile.write()`` method. All other methods are delegated to the
|
---|
| 1520 | underlying ``self.__outfile`` object. The delegation is accomplished via the
|
---|
| 1521 | ``__getattr__`` method; consult :ref:`the language reference <attribute-access>`
|
---|
| 1522 | for more information about controlling attribute access.
|
---|
| 1523 |
|
---|
| 1524 | Note that for more general cases delegation can get trickier. When attributes
|
---|
| 1525 | must be set as well as retrieved, the class must define a :meth:`__setattr__`
|
---|
| 1526 | method too, and it must do so carefully. The basic implementation of
|
---|
| 1527 | :meth:`__setattr__` is roughly equivalent to the following::
|
---|
| 1528 |
|
---|
| 1529 | class X:
|
---|
| 1530 | ...
|
---|
| 1531 | def __setattr__(self, name, value):
|
---|
| 1532 | self.__dict__[name] = value
|
---|
| 1533 | ...
|
---|
| 1534 |
|
---|
| 1535 | Most :meth:`__setattr__` implementations must modify ``self.__dict__`` to store
|
---|
| 1536 | local state for self without causing an infinite recursion.
|
---|
| 1537 |
|
---|
| 1538 |
|
---|
| 1539 | How do I call a method defined in a base class from a derived class that overrides it?
|
---|
| 1540 | --------------------------------------------------------------------------------------
|
---|
| 1541 |
|
---|
| 1542 | If you're using new-style classes, use the built-in :func:`super` function::
|
---|
| 1543 |
|
---|
| 1544 | class Derived(Base):
|
---|
| 1545 | def meth (self):
|
---|
| 1546 | super(Derived, self).meth()
|
---|
| 1547 |
|
---|
| 1548 | If you're using classic classes: For a class definition such as ``class
|
---|
| 1549 | Derived(Base): ...`` you can call method ``meth()`` defined in ``Base`` (or one
|
---|
| 1550 | of ``Base``'s base classes) as ``Base.meth(self, arguments...)``. Here,
|
---|
| 1551 | ``Base.meth`` is an unbound method, so you need to provide the ``self``
|
---|
| 1552 | argument.
|
---|
| 1553 |
|
---|
| 1554 |
|
---|
| 1555 | How can I organize my code to make it easier to change the base class?
|
---|
| 1556 | ----------------------------------------------------------------------
|
---|
| 1557 |
|
---|
| 1558 | You could define an alias for the base class, assign the real base class to it
|
---|
| 1559 | before your class definition, and use the alias throughout your class. Then all
|
---|
| 1560 | you have to change is the value assigned to the alias. Incidentally, this trick
|
---|
| 1561 | is also handy if you want to decide dynamically (e.g. depending on availability
|
---|
| 1562 | of resources) which base class to use. Example::
|
---|
| 1563 |
|
---|
| 1564 | BaseAlias = <real base class>
|
---|
| 1565 |
|
---|
| 1566 | class Derived(BaseAlias):
|
---|
| 1567 | def meth(self):
|
---|
| 1568 | BaseAlias.meth(self)
|
---|
| 1569 | ...
|
---|
| 1570 |
|
---|
| 1571 |
|
---|
| 1572 | How do I create static class data and static class methods?
|
---|
| 1573 | -----------------------------------------------------------
|
---|
| 1574 |
|
---|
[391] | 1575 | Both static data and static methods (in the sense of C++ or Java) are supported
|
---|
| 1576 | in Python.
|
---|
[2] | 1577 |
|
---|
| 1578 | For static data, simply define a class attribute. To assign a new value to the
|
---|
| 1579 | attribute, you have to explicitly use the class name in the assignment::
|
---|
| 1580 |
|
---|
| 1581 | class C:
|
---|
| 1582 | count = 0 # number of times C.__init__ called
|
---|
| 1583 |
|
---|
| 1584 | def __init__(self):
|
---|
| 1585 | C.count = C.count + 1
|
---|
| 1586 |
|
---|
| 1587 | def getcount(self):
|
---|
| 1588 | return C.count # or return self.count
|
---|
| 1589 |
|
---|
| 1590 | ``c.count`` also refers to ``C.count`` for any ``c`` such that ``isinstance(c,
|
---|
| 1591 | C)`` holds, unless overridden by ``c`` itself or by some class on the base-class
|
---|
| 1592 | search path from ``c.__class__`` back to ``C``.
|
---|
| 1593 |
|
---|
| 1594 | Caution: within a method of C, an assignment like ``self.count = 42`` creates a
|
---|
[391] | 1595 | new and unrelated instance named "count" in ``self``'s own dict. Rebinding of a
|
---|
| 1596 | class-static data name must always specify the class whether inside a method or
|
---|
| 1597 | not::
|
---|
[2] | 1598 |
|
---|
| 1599 | C.count = 314
|
---|
| 1600 |
|
---|
| 1601 | Static methods are possible since Python 2.2::
|
---|
| 1602 |
|
---|
| 1603 | class C:
|
---|
| 1604 | def static(arg1, arg2, arg3):
|
---|
| 1605 | # No 'self' parameter!
|
---|
| 1606 | ...
|
---|
| 1607 | static = staticmethod(static)
|
---|
| 1608 |
|
---|
| 1609 | With Python 2.4's decorators, this can also be written as ::
|
---|
| 1610 |
|
---|
| 1611 | class C:
|
---|
| 1612 | @staticmethod
|
---|
| 1613 | def static(arg1, arg2, arg3):
|
---|
| 1614 | # No 'self' parameter!
|
---|
| 1615 | ...
|
---|
| 1616 |
|
---|
| 1617 | However, a far more straightforward way to get the effect of a static method is
|
---|
| 1618 | via a simple module-level function::
|
---|
| 1619 |
|
---|
| 1620 | def getcount():
|
---|
| 1621 | return C.count
|
---|
| 1622 |
|
---|
| 1623 | If your code is structured so as to define one class (or tightly related class
|
---|
| 1624 | hierarchy) per module, this supplies the desired encapsulation.
|
---|
| 1625 |
|
---|
| 1626 |
|
---|
| 1627 | How can I overload constructors (or methods) in Python?
|
---|
| 1628 | -------------------------------------------------------
|
---|
| 1629 |
|
---|
| 1630 | This answer actually applies to all methods, but the question usually comes up
|
---|
| 1631 | first in the context of constructors.
|
---|
| 1632 |
|
---|
| 1633 | In C++ you'd write
|
---|
| 1634 |
|
---|
| 1635 | .. code-block:: c
|
---|
| 1636 |
|
---|
| 1637 | class C {
|
---|
| 1638 | C() { cout << "No arguments\n"; }
|
---|
| 1639 | C(int i) { cout << "Argument is " << i << "\n"; }
|
---|
| 1640 | }
|
---|
| 1641 |
|
---|
| 1642 | In Python you have to write a single constructor that catches all cases using
|
---|
| 1643 | default arguments. For example::
|
---|
| 1644 |
|
---|
| 1645 | class C:
|
---|
| 1646 | def __init__(self, i=None):
|
---|
| 1647 | if i is None:
|
---|
| 1648 | print "No arguments"
|
---|
| 1649 | else:
|
---|
| 1650 | print "Argument is", i
|
---|
| 1651 |
|
---|
| 1652 | This is not entirely equivalent, but close enough in practice.
|
---|
| 1653 |
|
---|
| 1654 | You could also try a variable-length argument list, e.g. ::
|
---|
| 1655 |
|
---|
| 1656 | def __init__(self, *args):
|
---|
| 1657 | ...
|
---|
| 1658 |
|
---|
| 1659 | The same approach works for all method definitions.
|
---|
| 1660 |
|
---|
| 1661 |
|
---|
| 1662 | I try to use __spam and I get an error about _SomeClassName__spam.
|
---|
| 1663 | ------------------------------------------------------------------
|
---|
| 1664 |
|
---|
| 1665 | Variable names with double leading underscores are "mangled" to provide a simple
|
---|
| 1666 | but effective way to define class private variables. Any identifier of the form
|
---|
| 1667 | ``__spam`` (at least two leading underscores, at most one trailing underscore)
|
---|
| 1668 | is textually replaced with ``_classname__spam``, where ``classname`` is the
|
---|
| 1669 | current class name with any leading underscores stripped.
|
---|
| 1670 |
|
---|
| 1671 | This doesn't guarantee privacy: an outside user can still deliberately access
|
---|
| 1672 | the "_classname__spam" attribute, and private values are visible in the object's
|
---|
| 1673 | ``__dict__``. Many Python programmers never bother to use private variable
|
---|
| 1674 | names at all.
|
---|
| 1675 |
|
---|
| 1676 |
|
---|
| 1677 | My class defines __del__ but it is not called when I delete the object.
|
---|
| 1678 | -----------------------------------------------------------------------
|
---|
| 1679 |
|
---|
| 1680 | There are several possible reasons for this.
|
---|
| 1681 |
|
---|
| 1682 | The del statement does not necessarily call :meth:`__del__` -- it simply
|
---|
| 1683 | decrements the object's reference count, and if this reaches zero
|
---|
| 1684 | :meth:`__del__` is called.
|
---|
| 1685 |
|
---|
| 1686 | If your data structures contain circular links (e.g. a tree where each child has
|
---|
| 1687 | a parent reference and each parent has a list of children) the reference counts
|
---|
| 1688 | will never go back to zero. Once in a while Python runs an algorithm to detect
|
---|
| 1689 | such cycles, but the garbage collector might run some time after the last
|
---|
| 1690 | reference to your data structure vanishes, so your :meth:`__del__` method may be
|
---|
| 1691 | called at an inconvenient and random time. This is inconvenient if you're trying
|
---|
| 1692 | to reproduce a problem. Worse, the order in which object's :meth:`__del__`
|
---|
| 1693 | methods are executed is arbitrary. You can run :func:`gc.collect` to force a
|
---|
| 1694 | collection, but there *are* pathological cases where objects will never be
|
---|
| 1695 | collected.
|
---|
| 1696 |
|
---|
| 1697 | Despite the cycle collector, it's still a good idea to define an explicit
|
---|
| 1698 | ``close()`` method on objects to be called whenever you're done with them. The
|
---|
| 1699 | ``close()`` method can then remove attributes that refer to subobjecs. Don't
|
---|
| 1700 | call :meth:`__del__` directly -- :meth:`__del__` should call ``close()`` and
|
---|
| 1701 | ``close()`` should make sure that it can be called more than once for the same
|
---|
| 1702 | object.
|
---|
| 1703 |
|
---|
| 1704 | Another way to avoid cyclical references is to use the :mod:`weakref` module,
|
---|
| 1705 | which allows you to point to objects without incrementing their reference count.
|
---|
| 1706 | Tree data structures, for instance, should use weak references for their parent
|
---|
| 1707 | and sibling references (if they need them!).
|
---|
| 1708 |
|
---|
| 1709 | If the object has ever been a local variable in a function that caught an
|
---|
| 1710 | expression in an except clause, chances are that a reference to the object still
|
---|
| 1711 | exists in that function's stack frame as contained in the stack trace.
|
---|
| 1712 | Normally, calling :func:`sys.exc_clear` will take care of this by clearing the
|
---|
| 1713 | last recorded exception.
|
---|
| 1714 |
|
---|
| 1715 | Finally, if your :meth:`__del__` method raises an exception, a warning message
|
---|
| 1716 | is printed to :data:`sys.stderr`.
|
---|
| 1717 |
|
---|
| 1718 |
|
---|
| 1719 | How do I get a list of all instances of a given class?
|
---|
| 1720 | ------------------------------------------------------
|
---|
| 1721 |
|
---|
| 1722 | Python does not keep track of all instances of a class (or of a built-in type).
|
---|
| 1723 | You can program the class's constructor to keep track of all instances by
|
---|
| 1724 | keeping a list of weak references to each instance.
|
---|
| 1725 |
|
---|
| 1726 |
|
---|
[391] | 1727 | Why does the result of ``id()`` appear to be not unique?
|
---|
| 1728 | --------------------------------------------------------
|
---|
| 1729 |
|
---|
| 1730 | The :func:`id` builtin returns an integer that is guaranteed to be unique during
|
---|
| 1731 | the lifetime of the object. Since in CPython, this is the object's memory
|
---|
| 1732 | address, it happens frequently that after an object is deleted from memory, the
|
---|
| 1733 | next freshly created object is allocated at the same position in memory. This
|
---|
| 1734 | is illustrated by this example:
|
---|
| 1735 |
|
---|
| 1736 | >>> id(1000)
|
---|
| 1737 | 13901272
|
---|
| 1738 | >>> id(2000)
|
---|
| 1739 | 13901272
|
---|
| 1740 |
|
---|
| 1741 | The two ids belong to different integer objects that are created before, and
|
---|
| 1742 | deleted immediately after execution of the ``id()`` call. To be sure that
|
---|
| 1743 | objects whose id you want to examine are still alive, create another reference
|
---|
| 1744 | to the object:
|
---|
| 1745 |
|
---|
| 1746 | >>> a = 1000; b = 2000
|
---|
| 1747 | >>> id(a)
|
---|
| 1748 | 13901272
|
---|
| 1749 | >>> id(b)
|
---|
| 1750 | 13891296
|
---|
| 1751 |
|
---|
| 1752 |
|
---|
[2] | 1753 | Modules
|
---|
| 1754 | =======
|
---|
| 1755 |
|
---|
| 1756 | How do I create a .pyc file?
|
---|
| 1757 | ----------------------------
|
---|
| 1758 |
|
---|
| 1759 | When a module is imported for the first time (or when the source is more recent
|
---|
| 1760 | than the current compiled file) a ``.pyc`` file containing the compiled code
|
---|
| 1761 | should be created in the same directory as the ``.py`` file.
|
---|
| 1762 |
|
---|
| 1763 | One reason that a ``.pyc`` file may not be created is permissions problems with
|
---|
| 1764 | the directory. This can happen, for example, if you develop as one user but run
|
---|
| 1765 | as another, such as if you are testing with a web server. Creation of a .pyc
|
---|
| 1766 | file is automatic if you're importing a module and Python has the ability
|
---|
| 1767 | (permissions, free space, etc...) to write the compiled module back to the
|
---|
| 1768 | directory.
|
---|
| 1769 |
|
---|
[391] | 1770 | Running Python on a top level script is not considered an import and no
|
---|
| 1771 | ``.pyc`` will be created. For example, if you have a top-level module
|
---|
| 1772 | ``foo.py`` that imports another module ``xyz.py``, when you run ``foo``,
|
---|
| 1773 | ``xyz.pyc`` will be created since ``xyz`` is imported, but no ``foo.pyc`` file
|
---|
| 1774 | will be created since ``foo.py`` isn't being imported.
|
---|
[2] | 1775 |
|
---|
[391] | 1776 | If you need to create ``foo.pyc`` -- that is, to create a ``.pyc`` file for a module
|
---|
[2] | 1777 | that is not imported -- you can, using the :mod:`py_compile` and
|
---|
| 1778 | :mod:`compileall` modules.
|
---|
| 1779 |
|
---|
| 1780 | The :mod:`py_compile` module can manually compile any module. One way is to use
|
---|
| 1781 | the ``compile()`` function in that module interactively::
|
---|
| 1782 |
|
---|
| 1783 | >>> import py_compile
|
---|
[391] | 1784 | >>> py_compile.compile('foo.py') # doctest: +SKIP
|
---|
[2] | 1785 |
|
---|
[391] | 1786 | This will write the ``.pyc`` to the same location as ``foo.py`` (or you can
|
---|
[2] | 1787 | override that with the optional parameter ``cfile``).
|
---|
| 1788 |
|
---|
| 1789 | You can also automatically compile all files in a directory or directories using
|
---|
| 1790 | the :mod:`compileall` module. You can do it from the shell prompt by running
|
---|
| 1791 | ``compileall.py`` and providing the path of a directory containing Python files
|
---|
| 1792 | to compile::
|
---|
| 1793 |
|
---|
| 1794 | python -m compileall .
|
---|
| 1795 |
|
---|
| 1796 |
|
---|
| 1797 | How do I find the current module name?
|
---|
| 1798 | --------------------------------------
|
---|
| 1799 |
|
---|
| 1800 | A module can find out its own module name by looking at the predefined global
|
---|
| 1801 | variable ``__name__``. If this has the value ``'__main__'``, the program is
|
---|
| 1802 | running as a script. Many modules that are usually used by importing them also
|
---|
| 1803 | provide a command-line interface or a self-test, and only execute this code
|
---|
| 1804 | after checking ``__name__``::
|
---|
| 1805 |
|
---|
| 1806 | def main():
|
---|
| 1807 | print 'Running test...'
|
---|
| 1808 | ...
|
---|
| 1809 |
|
---|
| 1810 | if __name__ == '__main__':
|
---|
| 1811 | main()
|
---|
| 1812 |
|
---|
| 1813 |
|
---|
| 1814 | How can I have modules that mutually import each other?
|
---|
| 1815 | -------------------------------------------------------
|
---|
| 1816 |
|
---|
| 1817 | Suppose you have the following modules:
|
---|
| 1818 |
|
---|
| 1819 | foo.py::
|
---|
| 1820 |
|
---|
| 1821 | from bar import bar_var
|
---|
| 1822 | foo_var = 1
|
---|
| 1823 |
|
---|
| 1824 | bar.py::
|
---|
| 1825 |
|
---|
| 1826 | from foo import foo_var
|
---|
| 1827 | bar_var = 2
|
---|
| 1828 |
|
---|
| 1829 | The problem is that the interpreter will perform the following steps:
|
---|
| 1830 |
|
---|
| 1831 | * main imports foo
|
---|
| 1832 | * Empty globals for foo are created
|
---|
| 1833 | * foo is compiled and starts executing
|
---|
| 1834 | * foo imports bar
|
---|
| 1835 | * Empty globals for bar are created
|
---|
| 1836 | * bar is compiled and starts executing
|
---|
| 1837 | * bar imports foo (which is a no-op since there already is a module named foo)
|
---|
| 1838 | * bar.foo_var = foo.foo_var
|
---|
| 1839 |
|
---|
| 1840 | The last step fails, because Python isn't done with interpreting ``foo`` yet and
|
---|
| 1841 | the global symbol dictionary for ``foo`` is still empty.
|
---|
| 1842 |
|
---|
| 1843 | The same thing happens when you use ``import foo``, and then try to access
|
---|
| 1844 | ``foo.foo_var`` in global code.
|
---|
| 1845 |
|
---|
| 1846 | There are (at least) three possible workarounds for this problem.
|
---|
| 1847 |
|
---|
| 1848 | Guido van Rossum recommends avoiding all uses of ``from <module> import ...``,
|
---|
| 1849 | and placing all code inside functions. Initializations of global variables and
|
---|
| 1850 | class variables should use constants or built-in functions only. This means
|
---|
| 1851 | everything from an imported module is referenced as ``<module>.<name>``.
|
---|
| 1852 |
|
---|
| 1853 | Jim Roskind suggests performing steps in the following order in each module:
|
---|
| 1854 |
|
---|
| 1855 | * exports (globals, functions, and classes that don't need imported base
|
---|
| 1856 | classes)
|
---|
| 1857 | * ``import`` statements
|
---|
| 1858 | * active code (including globals that are initialized from imported values).
|
---|
| 1859 |
|
---|
| 1860 | van Rossum doesn't like this approach much because the imports appear in a
|
---|
| 1861 | strange place, but it does work.
|
---|
| 1862 |
|
---|
| 1863 | Matthias Urlichs recommends restructuring your code so that the recursive import
|
---|
| 1864 | is not necessary in the first place.
|
---|
| 1865 |
|
---|
| 1866 | These solutions are not mutually exclusive.
|
---|
| 1867 |
|
---|
| 1868 |
|
---|
| 1869 | __import__('x.y.z') returns <module 'x'>; how do I get z?
|
---|
| 1870 | ---------------------------------------------------------
|
---|
| 1871 |
|
---|
| 1872 | Try::
|
---|
| 1873 |
|
---|
| 1874 | __import__('x.y.z').y.z
|
---|
| 1875 |
|
---|
| 1876 | For more realistic situations, you may have to do something like ::
|
---|
| 1877 |
|
---|
| 1878 | m = __import__(s)
|
---|
| 1879 | for i in s.split(".")[1:]:
|
---|
| 1880 | m = getattr(m, i)
|
---|
| 1881 |
|
---|
| 1882 | See :mod:`importlib` for a convenience function called
|
---|
| 1883 | :func:`~importlib.import_module`.
|
---|
| 1884 |
|
---|
| 1885 |
|
---|
| 1886 |
|
---|
| 1887 | When I edit an imported module and reimport it, the changes don't show up. Why does this happen?
|
---|
| 1888 | -------------------------------------------------------------------------------------------------
|
---|
| 1889 |
|
---|
| 1890 | For reasons of efficiency as well as consistency, Python only reads the module
|
---|
| 1891 | file on the first time a module is imported. If it didn't, in a program
|
---|
| 1892 | consisting of many modules where each one imports the same basic module, the
|
---|
| 1893 | basic module would be parsed and re-parsed many times. To force rereading of a
|
---|
| 1894 | changed module, do this::
|
---|
| 1895 |
|
---|
| 1896 | import modname
|
---|
| 1897 | reload(modname)
|
---|
| 1898 |
|
---|
| 1899 | Warning: this technique is not 100% fool-proof. In particular, modules
|
---|
| 1900 | containing statements like ::
|
---|
| 1901 |
|
---|
| 1902 | from modname import some_objects
|
---|
| 1903 |
|
---|
| 1904 | will continue to work with the old version of the imported objects. If the
|
---|
| 1905 | module contains class definitions, existing class instances will *not* be
|
---|
| 1906 | updated to use the new class definition. This can result in the following
|
---|
| 1907 | paradoxical behaviour:
|
---|
| 1908 |
|
---|
| 1909 | >>> import cls
|
---|
| 1910 | >>> c = cls.C() # Create an instance of C
|
---|
| 1911 | >>> reload(cls)
|
---|
| 1912 | <module 'cls' from 'cls.pyc'>
|
---|
| 1913 | >>> isinstance(c, cls.C) # isinstance is false?!?
|
---|
| 1914 | False
|
---|
| 1915 |
|
---|
| 1916 | The nature of the problem is made clear if you print out the class objects:
|
---|
| 1917 |
|
---|
| 1918 | >>> c.__class__
|
---|
| 1919 | <class cls.C at 0x7352a0>
|
---|
| 1920 | >>> cls.C
|
---|
| 1921 | <class cls.C at 0x4198d0>
|
---|
| 1922 |
|
---|