Georg Brandl | d741315 | 2009-10-11 21:25:26 +0000 | [diff] [blame] | 1 | ====================== |
| 2 | Design and History FAQ |
| 3 | ====================== |
| 4 | |
| 5 | Why does Python use indentation for grouping of statements? |
| 6 | ----------------------------------------------------------- |
| 7 | |
| 8 | Guido van Rossum believes that using indentation for grouping is extremely |
| 9 | elegant and contributes a lot to the clarity of the average Python program. |
| 10 | Most people learn to love this feature after awhile. |
| 11 | |
| 12 | Since there are no begin/end brackets there cannot be a disagreement between |
| 13 | grouping perceived by the parser and the human reader. Occasionally C |
| 14 | programmers will encounter a fragment of code like this:: |
| 15 | |
| 16 | if (x <= y) |
| 17 | x++; |
| 18 | y--; |
| 19 | z++; |
| 20 | |
| 21 | Only the ``x++`` statement is executed if the condition is true, but the |
| 22 | indentation leads you to believe otherwise. Even experienced C programmers will |
| 23 | sometimes stare at it a long time wondering why ``y`` is being decremented even |
| 24 | for ``x > y``. |
| 25 | |
| 26 | Because there are no begin/end brackets, Python is much less prone to |
| 27 | coding-style conflicts. In C there are many different ways to place the braces. |
| 28 | If you're used to reading and writing code that uses one style, you will feel at |
| 29 | least slightly uneasy when reading (or being required to write) another style. |
| 30 | |
| 31 | Many coding styles place begin/end brackets on a line by themself. This makes |
| 32 | programs considerably longer and wastes valuable screen space, making it harder |
| 33 | to get a good overview of a program. Ideally, a function should fit on one |
| 34 | screen (say, 20-30 lines). 20 lines of Python can do a lot more work than 20 |
| 35 | lines of C. This is not solely due to the lack of begin/end brackets -- the |
| 36 | lack of declarations and the high-level data types are also responsible -- but |
| 37 | the indentation-based syntax certainly helps. |
| 38 | |
| 39 | |
| 40 | Why am I getting strange results with simple arithmetic operations? |
| 41 | ------------------------------------------------------------------- |
| 42 | |
| 43 | See the next question. |
| 44 | |
| 45 | |
| 46 | Why are floating point calculations so inaccurate? |
| 47 | -------------------------------------------------- |
| 48 | |
| 49 | People are often very surprised by results like this:: |
| 50 | |
| 51 | >>> 1.2-1.0 |
| 52 | 0.199999999999999996 |
| 53 | |
| 54 | and think it is a bug in Python. It's not. This has nothing to do with Python, |
| 55 | but with how the underlying C platform handles floating point numbers, and |
| 56 | ultimately with the inaccuracies introduced when writing down numbers as a |
| 57 | string of a fixed number of digits. |
| 58 | |
| 59 | The internal representation of floating point numbers uses a fixed number of |
| 60 | binary digits to represent a decimal number. Some decimal numbers can't be |
| 61 | represented exactly in binary, resulting in small roundoff errors. |
| 62 | |
| 63 | In decimal math, there are many numbers that can't be represented with a fixed |
| 64 | number of decimal digits, e.g. 1/3 = 0.3333333333....... |
| 65 | |
| 66 | In base 2, 1/2 = 0.1, 1/4 = 0.01, 1/8 = 0.001, etc. .2 equals 2/10 equals 1/5, |
| 67 | resulting in the binary fractional number 0.001100110011001... |
| 68 | |
| 69 | Floating point numbers only have 32 or 64 bits of precision, so the digits are |
| 70 | cut off at some point, and the resulting number is 0.199999999999999996 in |
| 71 | decimal, not 0.2. |
| 72 | |
| 73 | A floating point number's ``repr()`` function prints as many digits are |
| 74 | necessary to make ``eval(repr(f)) == f`` true for any float f. The ``str()`` |
| 75 | function prints fewer digits and this often results in the more sensible number |
| 76 | that was probably intended:: |
| 77 | |
Mark Dickinson | a63b306 | 2009-11-24 14:33:29 +0000 | [diff] [blame] | 78 | >>> 1.1 - 0.9 |
| 79 | 0.20000000000000007 |
| 80 | >>> print(1.1 - 0.9) |
Georg Brandl | d741315 | 2009-10-11 21:25:26 +0000 | [diff] [blame] | 81 | 0.2 |
| 82 | |
| 83 | One of the consequences of this is that it is error-prone to compare the result |
| 84 | of some computation to a float with ``==``. Tiny inaccuracies may mean that |
| 85 | ``==`` fails. Instead, you have to check that the difference between the two |
| 86 | numbers is less than a certain threshold:: |
| 87 | |
| 88 | epsilon = 0.0000000000001 # Tiny allowed error |
| 89 | expected_result = 0.4 |
| 90 | |
| 91 | if expected_result-epsilon <= computation() <= expected_result+epsilon: |
| 92 | ... |
| 93 | |
| 94 | Please see the chapter on :ref:`floating point arithmetic <tut-fp-issues>` in |
| 95 | the Python tutorial for more information. |
| 96 | |
| 97 | |
| 98 | Why are Python strings immutable? |
| 99 | --------------------------------- |
| 100 | |
| 101 | There are several advantages. |
| 102 | |
| 103 | One is performance: knowing that a string is immutable means we can allocate |
| 104 | space for it at creation time, and the storage requirements are fixed and |
| 105 | unchanging. This is also one of the reasons for the distinction between tuples |
| 106 | and lists. |
| 107 | |
| 108 | Another advantage is that strings in Python are considered as "elemental" as |
| 109 | numbers. No amount of activity will change the value 8 to anything else, and in |
| 110 | Python, no amount of activity will change the string "eight" to anything else. |
| 111 | |
| 112 | |
| 113 | .. _why-self: |
| 114 | |
| 115 | Why must 'self' be used explicitly in method definitions and calls? |
| 116 | ------------------------------------------------------------------- |
| 117 | |
| 118 | The idea was borrowed from Modula-3. It turns out to be very useful, for a |
| 119 | variety of reasons. |
| 120 | |
| 121 | First, it's more obvious that you are using a method or instance attribute |
| 122 | instead of a local variable. Reading ``self.x`` or ``self.meth()`` makes it |
| 123 | absolutely clear that an instance variable or method is used even if you don't |
| 124 | know the class definition by heart. In C++, you can sort of tell by the lack of |
| 125 | a local variable declaration (assuming globals are rare or easily recognizable) |
| 126 | -- but in Python, there are no local variable declarations, so you'd have to |
| 127 | look up the class definition to be sure. Some C++ and Java coding standards |
| 128 | call for instance attributes to have an ``m_`` prefix, so this explicitness is |
| 129 | still useful in those languages, too. |
| 130 | |
| 131 | Second, it means that no special syntax is necessary if you want to explicitly |
| 132 | reference or call the method from a particular class. In C++, if you want to |
| 133 | use a method from a base class which is overridden in a derived class, you have |
| 134 | to use the ``::`` operator -- in Python you can write baseclass.methodname(self, |
| 135 | <argument list>). This is particularly useful for :meth:`__init__` methods, and |
| 136 | in general in cases where a derived class method wants to extend the base class |
| 137 | method of the same name and thus has to call the base class method somehow. |
| 138 | |
| 139 | Finally, for instance variables it solves a syntactic problem with assignment: |
| 140 | since local variables in Python are (by definition!) those variables to which a |
| 141 | value assigned in a function body (and that aren't explicitly declared global), |
| 142 | there has to be some way to tell the interpreter that an assignment was meant to |
| 143 | assign to an instance variable instead of to a local variable, and it should |
| 144 | preferably be syntactic (for efficiency reasons). C++ does this through |
| 145 | declarations, but Python doesn't have declarations and it would be a pity having |
| 146 | to introduce them just for this purpose. Using the explicit "self.var" solves |
| 147 | this nicely. Similarly, for using instance variables, having to write |
| 148 | "self.var" means that references to unqualified names inside a method don't have |
| 149 | to search the instance's directories. To put it another way, local variables |
| 150 | and instance variables live in two different namespaces, and you need to tell |
| 151 | Python which namespace to use. |
| 152 | |
| 153 | |
| 154 | Why can't I use an assignment in an expression? |
| 155 | ----------------------------------------------- |
| 156 | |
| 157 | Many people used to C or Perl complain that they want to use this C idiom: |
| 158 | |
| 159 | .. code-block:: c |
| 160 | |
| 161 | while (line = readline(f)) { |
| 162 | // do something with line |
| 163 | } |
| 164 | |
| 165 | where in Python you're forced to write this:: |
| 166 | |
| 167 | while True: |
| 168 | line = f.readline() |
| 169 | if not line: |
| 170 | break |
| 171 | ... # do something with line |
| 172 | |
| 173 | The reason for not allowing assignment in Python expressions is a common, |
| 174 | hard-to-find bug in those other languages, caused by this construct: |
| 175 | |
| 176 | .. code-block:: c |
| 177 | |
| 178 | if (x = 0) { |
| 179 | // error handling |
| 180 | } |
| 181 | else { |
| 182 | // code that only works for nonzero x |
| 183 | } |
| 184 | |
| 185 | The error is a simple typo: ``x = 0``, which assigns 0 to the variable ``x``, |
| 186 | was written while the comparison ``x == 0`` is certainly what was intended. |
| 187 | |
| 188 | Many alternatives have been proposed. Most are hacks that save some typing but |
| 189 | use arbitrary or cryptic syntax or keywords, and fail the simple criterion for |
| 190 | language change proposals: it should intuitively suggest the proper meaning to a |
| 191 | human reader who has not yet been introduced to the construct. |
| 192 | |
| 193 | An interesting phenomenon is that most experienced Python programmers recognize |
| 194 | the ``while True`` idiom and don't seem to be missing the assignment in |
| 195 | expression construct much; it's only newcomers who express a strong desire to |
| 196 | add this to the language. |
| 197 | |
| 198 | There's an alternative way of spelling this that seems attractive but is |
| 199 | generally less robust than the "while True" solution:: |
| 200 | |
| 201 | line = f.readline() |
| 202 | while line: |
| 203 | ... # do something with line... |
| 204 | line = f.readline() |
| 205 | |
| 206 | The problem with this is that if you change your mind about exactly how you get |
| 207 | the next line (e.g. you want to change it into ``sys.stdin.readline()``) you |
| 208 | have to remember to change two places in your program -- the second occurrence |
| 209 | is hidden at the bottom of the loop. |
| 210 | |
| 211 | The best approach is to use iterators, making it possible to loop through |
| 212 | objects using the ``for`` statement. For example, in the current version of |
| 213 | Python file objects support the iterator protocol, so you can now write simply:: |
| 214 | |
| 215 | for line in f: |
| 216 | ... # do something with line... |
| 217 | |
| 218 | |
| 219 | |
| 220 | Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))? |
| 221 | ---------------------------------------------------------------------------------------------------------------- |
| 222 | |
| 223 | The major reason is history. Functions were used for those operations that were |
| 224 | generic for a group of types and which were intended to work even for objects |
| 225 | that didn't have methods at all (e.g. tuples). It is also convenient to have a |
| 226 | function that can readily be applied to an amorphous collection of objects when |
| 227 | you use the functional features of Python (``map()``, ``apply()`` et al). |
| 228 | |
| 229 | In fact, implementing ``len()``, ``max()``, ``min()`` as a built-in function is |
| 230 | actually less code than implementing them as methods for each type. One can |
| 231 | quibble about individual cases but it's a part of Python, and it's too late to |
| 232 | make such fundamental changes now. The functions have to remain to avoid massive |
| 233 | code breakage. |
| 234 | |
| 235 | .. XXX talk about protocols? |
| 236 | |
Georg Brandl | bfe95ac | 2009-12-19 17:46:40 +0000 | [diff] [blame^] | 237 | .. note:: |
| 238 | |
| 239 | For string operations, Python has moved from external functions (the |
| 240 | ``string`` module) to methods. However, ``len()`` is still a function. |
Georg Brandl | d741315 | 2009-10-11 21:25:26 +0000 | [diff] [blame] | 241 | |
| 242 | |
| 243 | Why is join() a string method instead of a list or tuple method? |
| 244 | ---------------------------------------------------------------- |
| 245 | |
| 246 | Strings became much more like other standard types starting in Python 1.6, when |
| 247 | methods were added which give the same functionality that has always been |
| 248 | available using the functions of the string module. Most of these new methods |
| 249 | have been widely accepted, but the one which appears to make some programmers |
| 250 | feel uncomfortable is:: |
| 251 | |
| 252 | ", ".join(['1', '2', '4', '8', '16']) |
| 253 | |
| 254 | which gives the result:: |
| 255 | |
| 256 | "1, 2, 4, 8, 16" |
| 257 | |
| 258 | There are two common arguments against this usage. |
| 259 | |
| 260 | The first runs along the lines of: "It looks really ugly using a method of a |
| 261 | string literal (string constant)", to which the answer is that it might, but a |
| 262 | string literal is just a fixed value. If the methods are to be allowed on names |
| 263 | bound to strings there is no logical reason to make them unavailable on |
| 264 | literals. |
| 265 | |
| 266 | The second objection is typically cast as: "I am really telling a sequence to |
| 267 | join its members together with a string constant". Sadly, you aren't. For some |
| 268 | reason there seems to be much less difficulty with having :meth:`~str.split` as |
| 269 | a string method, since in that case it is easy to see that :: |
| 270 | |
| 271 | "1, 2, 4, 8, 16".split(", ") |
| 272 | |
| 273 | is an instruction to a string literal to return the substrings delimited by the |
| 274 | given separator (or, by default, arbitrary runs of white space). In this case a |
| 275 | Unicode string returns a list of Unicode strings, an ASCII string returns a list |
| 276 | of ASCII strings, and everyone is happy. |
| 277 | |
| 278 | :meth:`~str.join` is a string method because in using it you are telling the |
| 279 | separator string to iterate over a sequence of strings and insert itself between |
| 280 | adjacent elements. This method can be used with any argument which obeys the |
| 281 | rules for sequence objects, including any new classes you might define yourself. |
| 282 | |
| 283 | Because this is a string method it can work for Unicode strings as well as plain |
| 284 | ASCII strings. If ``join()`` were a method of the sequence types then the |
| 285 | sequence types would have to decide which type of string to return depending on |
| 286 | the type of the separator. |
| 287 | |
| 288 | .. XXX remove next paragraph eventually |
| 289 | |
| 290 | If none of these arguments persuade you, then for the moment you can continue to |
| 291 | use the ``join()`` function from the string module, which allows you to write :: |
| 292 | |
| 293 | string.join(['1', '2', '4', '8', '16'], ", ") |
| 294 | |
| 295 | |
| 296 | How fast are exceptions? |
| 297 | ------------------------ |
| 298 | |
| 299 | A try/except block is extremely efficient. Actually catching an exception is |
| 300 | expensive. In versions of Python prior to 2.0 it was common to use this idiom:: |
| 301 | |
| 302 | try: |
| 303 | value = dict[key] |
| 304 | except KeyError: |
| 305 | dict[key] = getvalue(key) |
| 306 | value = dict[key] |
| 307 | |
| 308 | This only made sense when you expected the dict to have the key almost all the |
| 309 | time. If that wasn't the case, you coded it like this:: |
| 310 | |
Georg Brandl | bfe95ac | 2009-12-19 17:46:40 +0000 | [diff] [blame^] | 311 | if key in dict(key): |
Georg Brandl | d741315 | 2009-10-11 21:25:26 +0000 | [diff] [blame] | 312 | value = dict[key] |
| 313 | else: |
| 314 | dict[key] = getvalue(key) |
| 315 | value = dict[key] |
| 316 | |
Georg Brandl | bfe95ac | 2009-12-19 17:46:40 +0000 | [diff] [blame^] | 317 | For this specific case, you could also use ``value = dict.setdefault(key, |
| 318 | getvalue(key))``, but only if the ``getvalue()`` call is cheap enough because it |
| 319 | is evaluated in all cases. |
Georg Brandl | d741315 | 2009-10-11 21:25:26 +0000 | [diff] [blame] | 320 | |
| 321 | |
| 322 | Why isn't there a switch or case statement in Python? |
| 323 | ----------------------------------------------------- |
| 324 | |
| 325 | You can do this easily enough with a sequence of ``if... elif... elif... else``. |
| 326 | There have been some proposals for switch statement syntax, but there is no |
| 327 | consensus (yet) on whether and how to do range tests. See :pep:`275` for |
| 328 | complete details and the current status. |
| 329 | |
| 330 | For cases where you need to choose from a very large number of possibilities, |
| 331 | you can create a dictionary mapping case values to functions to call. For |
| 332 | example:: |
| 333 | |
| 334 | def function_1(...): |
| 335 | ... |
| 336 | |
| 337 | functions = {'a': function_1, |
| 338 | 'b': function_2, |
| 339 | 'c': self.method_1, ...} |
| 340 | |
| 341 | func = functions[value] |
| 342 | func() |
| 343 | |
| 344 | For calling methods on objects, you can simplify yet further by using the |
| 345 | :func:`getattr` built-in to retrieve methods with a particular name:: |
| 346 | |
| 347 | def visit_a(self, ...): |
| 348 | ... |
| 349 | ... |
| 350 | |
| 351 | def dispatch(self, value): |
| 352 | method_name = 'visit_' + str(value) |
| 353 | method = getattr(self, method_name) |
| 354 | method() |
| 355 | |
| 356 | It's suggested that you use a prefix for the method names, such as ``visit_`` in |
| 357 | this example. Without such a prefix, if values are coming from an untrusted |
| 358 | source, an attacker would be able to call any method on your object. |
| 359 | |
| 360 | |
| 361 | Can't you emulate threads in the interpreter instead of relying on an OS-specific thread implementation? |
| 362 | -------------------------------------------------------------------------------------------------------- |
| 363 | |
| 364 | Answer 1: Unfortunately, the interpreter pushes at least one C stack frame for |
| 365 | each Python stack frame. Also, extensions can call back into Python at almost |
| 366 | random moments. Therefore, a complete threads implementation requires thread |
| 367 | support for C. |
| 368 | |
| 369 | Answer 2: Fortunately, there is `Stackless Python <http://www.stackless.com>`_, |
| 370 | which has a completely redesigned interpreter loop that avoids the C stack. |
| 371 | It's still experimental but looks very promising. Although it is binary |
| 372 | compatible with standard Python, it's still unclear whether Stackless will make |
| 373 | it into the core -- maybe it's just too revolutionary. |
| 374 | |
| 375 | |
| 376 | Why can't lambda forms contain statements? |
| 377 | ------------------------------------------ |
| 378 | |
| 379 | Python lambda forms cannot contain statements because Python's syntactic |
| 380 | framework can't handle statements nested inside expressions. However, in |
| 381 | Python, this is not a serious problem. Unlike lambda forms in other languages, |
| 382 | where they add functionality, Python lambdas are only a shorthand notation if |
| 383 | you're too lazy to define a function. |
| 384 | |
| 385 | Functions are already first class objects in Python, and can be declared in a |
| 386 | local scope. Therefore the only advantage of using a lambda form instead of a |
| 387 | locally-defined function is that you don't need to invent a name for the |
| 388 | function -- but that's just a local variable to which the function object (which |
| 389 | is exactly the same type of object that a lambda form yields) is assigned! |
| 390 | |
| 391 | |
| 392 | Can Python be compiled to machine code, C or some other language? |
| 393 | ----------------------------------------------------------------- |
| 394 | |
| 395 | Not easily. Python's high level data types, dynamic typing of objects and |
| 396 | run-time invocation of the interpreter (using :func:`eval` or :keyword:`exec`) |
| 397 | together mean that a "compiled" Python program would probably consist mostly of |
| 398 | calls into the Python run-time system, even for seemingly simple operations like |
| 399 | ``x+1``. |
| 400 | |
| 401 | Several projects described in the Python newsgroup or at past `Python |
Georg Brandl | 495f7b5 | 2009-10-27 15:28:25 +0000 | [diff] [blame] | 402 | conferences <http://python.org/community/workshops/>`_ have shown that this |
| 403 | approach is feasible, although the speedups reached so far are only modest |
| 404 | (e.g. 2x). Jython uses the same strategy for compiling to Java bytecode. (Jim |
| 405 | Hugunin has demonstrated that in combination with whole-program analysis, |
| 406 | speedups of 1000x are feasible for small demo programs. See the proceedings |
| 407 | from the `1997 Python conference |
| 408 | <http://python.org/workshops/1997-10/proceedings/>`_ for more information.) |
Georg Brandl | d741315 | 2009-10-11 21:25:26 +0000 | [diff] [blame] | 409 | |
| 410 | Internally, Python source code is always translated into a bytecode |
| 411 | representation, and this bytecode is then executed by the Python virtual |
| 412 | machine. In order to avoid the overhead of repeatedly parsing and translating |
| 413 | modules that rarely change, this byte code is written into a file whose name |
| 414 | ends in ".pyc" whenever a module is parsed. When the corresponding .py file is |
| 415 | changed, it is parsed and translated again and the .pyc file is rewritten. |
| 416 | |
| 417 | There is no performance difference once the .pyc file has been loaded, as the |
| 418 | bytecode read from the .pyc file is exactly the same as the bytecode created by |
| 419 | direct translation. The only difference is that loading code from a .pyc file |
| 420 | is faster than parsing and translating a .py file, so the presence of |
| 421 | precompiled .pyc files improves the start-up time of Python scripts. If |
| 422 | desired, the Lib/compileall.py module can be used to create valid .pyc files for |
| 423 | a given set of modules. |
| 424 | |
| 425 | Note that the main script executed by Python, even if its filename ends in .py, |
| 426 | is not compiled to a .pyc file. It is compiled to bytecode, but the bytecode is |
| 427 | not saved to a file. Usually main scripts are quite short, so this doesn't cost |
| 428 | much speed. |
| 429 | |
| 430 | .. XXX check which of these projects are still alive |
| 431 | |
| 432 | There are also several programs which make it easier to intermingle Python and C |
| 433 | code in various ways to increase performance. See, for example, `Psyco |
| 434 | <http://psyco.sourceforge.net/>`_, `Pyrex |
| 435 | <http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/>`_, `PyInline |
| 436 | <http://pyinline.sourceforge.net/>`_, `Py2Cmod |
| 437 | <http://sourceforge.net/projects/py2cmod/>`_, and `Weave |
| 438 | <http://www.scipy.org/site_content/weave>`_. |
| 439 | |
| 440 | |
| 441 | How does Python manage memory? |
| 442 | ------------------------------ |
| 443 | |
| 444 | The details of Python memory management depend on the implementation. The |
| 445 | standard C implementation of Python uses reference counting to detect |
| 446 | inaccessible objects, and another mechanism to collect reference cycles, |
| 447 | periodically executing a cycle detection algorithm which looks for inaccessible |
| 448 | cycles and deletes the objects involved. The :mod:`gc` module provides functions |
| 449 | to perform a garbage collection, obtain debugging statistics, and tune the |
| 450 | collector's parameters. |
| 451 | |
| 452 | Jython relies on the Java runtime so the JVM's garbage collector is used. This |
| 453 | difference can cause some subtle porting problems if your Python code depends on |
| 454 | the behavior of the reference counting implementation. |
| 455 | |
| 456 | Sometimes objects get stuck in tracebacks temporarily and hence are not |
| 457 | deallocated when you might expect. Clear the tracebacks with:: |
| 458 | |
| 459 | import sys |
| 460 | sys.exc_clear() |
| 461 | sys.exc_traceback = sys.last_traceback = None |
| 462 | |
| 463 | Tracebacks are used for reporting errors, implementing debuggers and related |
| 464 | things. They contain a portion of the program state extracted during the |
| 465 | handling of an exception (usually the most recent exception). |
| 466 | |
| 467 | In the absence of circularities and tracebacks, Python programs need not |
| 468 | explicitly manage memory. |
| 469 | |
| 470 | Why doesn't Python use a more traditional garbage collection scheme? For one |
| 471 | thing, this is not a C standard feature and hence it's not portable. (Yes, we |
| 472 | know about the Boehm GC library. It has bits of assembler code for *most* |
| 473 | common platforms, not for all of them, and although it is mostly transparent, it |
| 474 | isn't completely transparent; patches are required to get Python to work with |
| 475 | it.) |
| 476 | |
| 477 | Traditional GC also becomes a problem when Python is embedded into other |
| 478 | applications. While in a standalone Python it's fine to replace the standard |
| 479 | malloc() and free() with versions provided by the GC library, an application |
| 480 | embedding Python may want to have its *own* substitute for malloc() and free(), |
| 481 | and may not want Python's. Right now, Python works with anything that |
| 482 | implements malloc() and free() properly. |
| 483 | |
| 484 | In Jython, the following code (which is fine in CPython) will probably run out |
| 485 | of file descriptors long before it runs out of memory:: |
| 486 | |
| 487 | for file in <very long list of files>: |
| 488 | f = open(file) |
| 489 | c = f.read(1) |
| 490 | |
| 491 | Using the current reference counting and destructor scheme, each new assignment |
| 492 | to f closes the previous file. Using GC, this is not guaranteed. If you want |
| 493 | to write code that will work with any Python implementation, you should |
| 494 | explicitly close the file; this will work regardless of GC:: |
| 495 | |
| 496 | for file in <very long list of files>: |
| 497 | f = open(file) |
| 498 | c = f.read(1) |
| 499 | f.close() |
| 500 | |
| 501 | |
| 502 | Why isn't all memory freed when Python exits? |
| 503 | --------------------------------------------- |
| 504 | |
| 505 | Objects referenced from the global namespaces of Python modules are not always |
| 506 | deallocated when Python exits. This may happen if there are circular |
| 507 | references. There are also certain bits of memory that are allocated by the C |
| 508 | library that are impossible to free (e.g. a tool like Purify will complain about |
| 509 | these). Python is, however, aggressive about cleaning up memory on exit and |
| 510 | does try to destroy every single object. |
| 511 | |
| 512 | If you want to force Python to delete certain things on deallocation use the |
| 513 | :mod:`atexit` module to run a function that will force those deletions. |
| 514 | |
| 515 | |
| 516 | Why are there separate tuple and list data types? |
| 517 | ------------------------------------------------- |
| 518 | |
| 519 | Lists and tuples, while similar in many respects, are generally used in |
| 520 | fundamentally different ways. Tuples can be thought of as being similar to |
| 521 | Pascal records or C structs; they're small collections of related data which may |
| 522 | be of different types which are operated on as a group. For example, a |
| 523 | Cartesian coordinate is appropriately represented as a tuple of two or three |
| 524 | numbers. |
| 525 | |
| 526 | Lists, on the other hand, are more like arrays in other languages. They tend to |
| 527 | hold a varying number of objects all of which have the same type and which are |
| 528 | operated on one-by-one. For example, ``os.listdir('.')`` returns a list of |
| 529 | strings representing the files in the current directory. Functions which |
| 530 | operate on this output would generally not break if you added another file or |
| 531 | two to the directory. |
| 532 | |
| 533 | Tuples are immutable, meaning that once a tuple has been created, you can't |
| 534 | replace any of its elements with a new value. Lists are mutable, meaning that |
| 535 | you can always change a list's elements. Only immutable elements can be used as |
| 536 | dictionary keys, and hence only tuples and not lists can be used as keys. |
| 537 | |
| 538 | |
| 539 | How are lists implemented? |
| 540 | -------------------------- |
| 541 | |
| 542 | Python's lists are really variable-length arrays, not Lisp-style linked lists. |
| 543 | The implementation uses a contiguous array of references to other objects, and |
| 544 | keeps a pointer to this array and the array's length in a list head structure. |
| 545 | |
| 546 | This makes indexing a list ``a[i]`` an operation whose cost is independent of |
| 547 | the size of the list or the value of the index. |
| 548 | |
| 549 | When items are appended or inserted, the array of references is resized. Some |
| 550 | cleverness is applied to improve the performance of appending items repeatedly; |
| 551 | when the array must be grown, some extra space is allocated so the next few |
| 552 | times don't require an actual resize. |
| 553 | |
| 554 | |
| 555 | How are dictionaries implemented? |
| 556 | --------------------------------- |
| 557 | |
| 558 | Python's dictionaries are implemented as resizable hash tables. Compared to |
| 559 | B-trees, this gives better performance for lookup (the most common operation by |
| 560 | far) under most circumstances, and the implementation is simpler. |
| 561 | |
| 562 | Dictionaries work by computing a hash code for each key stored in the dictionary |
| 563 | using the :func:`hash` built-in function. The hash code varies widely depending |
| 564 | on the key; for example, "Python" hashes to -539294296 while "python", a string |
| 565 | that differs by a single bit, hashes to 1142331976. The hash code is then used |
| 566 | to calculate a location in an internal array where the value will be stored. |
| 567 | Assuming that you're storing keys that all have different hash values, this |
| 568 | means that dictionaries take constant time -- O(1), in computer science notation |
| 569 | -- to retrieve a key. It also means that no sorted order of the keys is |
| 570 | maintained, and traversing the array as the ``.keys()`` and ``.items()`` do will |
| 571 | output the dictionary's content in some arbitrary jumbled order. |
| 572 | |
| 573 | |
| 574 | Why must dictionary keys be immutable? |
| 575 | -------------------------------------- |
| 576 | |
| 577 | The hash table implementation of dictionaries uses a hash value calculated from |
| 578 | the key value to find the key. If the key were a mutable object, its value |
| 579 | could change, and thus its hash could also change. But since whoever changes |
| 580 | the key object can't tell that it was being used as a dictionary key, it can't |
| 581 | move the entry around in the dictionary. Then, when you try to look up the same |
| 582 | object in the dictionary it won't be found because its hash value is different. |
| 583 | If you tried to look up the old value it wouldn't be found either, because the |
| 584 | value of the object found in that hash bin would be different. |
| 585 | |
| 586 | If you want a dictionary indexed with a list, simply convert the list to a tuple |
| 587 | first; the function ``tuple(L)`` creates a tuple with the same entries as the |
| 588 | list ``L``. Tuples are immutable and can therefore be used as dictionary keys. |
| 589 | |
| 590 | Some unacceptable solutions that have been proposed: |
| 591 | |
| 592 | - Hash lists by their address (object ID). This doesn't work because if you |
| 593 | construct a new list with the same value it won't be found; e.g.:: |
| 594 | |
| 595 | d = {[1,2]: '12'} |
| 596 | print d[[1,2]] |
| 597 | |
| 598 | would raise a KeyError exception because the id of the ``[1,2]`` used in the |
| 599 | second line differs from that in the first line. In other words, dictionary |
| 600 | keys should be compared using ``==``, not using :keyword:`is`. |
| 601 | |
| 602 | - Make a copy when using a list as a key. This doesn't work because the list, |
| 603 | being a mutable object, could contain a reference to itself, and then the |
| 604 | copying code would run into an infinite loop. |
| 605 | |
| 606 | - Allow lists as keys but tell the user not to modify them. This would allow a |
| 607 | class of hard-to-track bugs in programs when you forgot or modified a list by |
| 608 | accident. It also invalidates an important invariant of dictionaries: every |
| 609 | value in ``d.keys()`` is usable as a key of the dictionary. |
| 610 | |
| 611 | - Mark lists as read-only once they are used as a dictionary key. The problem |
| 612 | is that it's not just the top-level object that could change its value; you |
| 613 | could use a tuple containing a list as a key. Entering anything as a key into |
| 614 | a dictionary would require marking all objects reachable from there as |
| 615 | read-only -- and again, self-referential objects could cause an infinite loop. |
| 616 | |
| 617 | There is a trick to get around this if you need to, but use it at your own risk: |
| 618 | You can wrap a mutable structure inside a class instance which has both a |
| 619 | :meth:`__cmp_` and a :meth:`__hash__` method. You must then make sure that the |
| 620 | hash value for all such wrapper objects that reside in a dictionary (or other |
| 621 | hash based structure), remain fixed while the object is in the dictionary (or |
| 622 | other structure). :: |
| 623 | |
| 624 | class ListWrapper: |
| 625 | def __init__(self, the_list): |
| 626 | self.the_list = the_list |
| 627 | def __cmp__(self, other): |
| 628 | return self.the_list == other.the_list |
| 629 | def __hash__(self): |
| 630 | l = self.the_list |
| 631 | result = 98767 - len(l)*555 |
| 632 | for i in range(len(l)): |
| 633 | try: |
| 634 | result = result + (hash(l[i]) % 9999999) * 1001 + i |
| 635 | except: |
| 636 | result = (result % 7777777) + i * 333 |
| 637 | return result |
| 638 | |
| 639 | Note that the hash computation is complicated by the possibility that some |
| 640 | members of the list may be unhashable and also by the possibility of arithmetic |
| 641 | overflow. |
| 642 | |
| 643 | Furthermore it must always be the case that if ``o1 == o2`` (ie ``o1.__cmp__(o2) |
| 644 | == 0``) then ``hash(o1) == hash(o2)`` (ie, ``o1.__hash__() == o2.__hash__()``), |
| 645 | regardless of whether the object is in a dictionary or not. If you fail to meet |
| 646 | these restrictions dictionaries and other hash based structures will misbehave. |
| 647 | |
| 648 | In the case of ListWrapper, whenever the wrapper object is in a dictionary the |
| 649 | wrapped list must not change to avoid anomalies. Don't do this unless you are |
| 650 | prepared to think hard about the requirements and the consequences of not |
| 651 | meeting them correctly. Consider yourself warned. |
| 652 | |
| 653 | |
| 654 | Why doesn't list.sort() return the sorted list? |
| 655 | ----------------------------------------------- |
| 656 | |
| 657 | In situations where performance matters, making a copy of the list just to sort |
| 658 | it would be wasteful. Therefore, :meth:`list.sort` sorts the list in place. In |
| 659 | order to remind you of that fact, it does not return the sorted list. This way, |
| 660 | you won't be fooled into accidentally overwriting a list when you need a sorted |
| 661 | copy but also need to keep the unsorted version around. |
| 662 | |
| 663 | In Python 2.4 a new builtin -- :func:`sorted` -- has been added. This function |
| 664 | creates a new list from a provided iterable, sorts it and returns it. For |
| 665 | example, here's how to iterate over the keys of a dictionary in sorted order:: |
| 666 | |
| 667 | for key in sorted(dict.iterkeys()): |
| 668 | ... # do whatever with dict[key]... |
| 669 | |
| 670 | |
| 671 | How do you specify and enforce an interface spec in Python? |
| 672 | ----------------------------------------------------------- |
| 673 | |
| 674 | An interface specification for a module as provided by languages such as C++ and |
| 675 | Java describes the prototypes for the methods and functions of the module. Many |
| 676 | feel that compile-time enforcement of interface specifications helps in the |
| 677 | construction of large programs. |
| 678 | |
| 679 | Python 2.6 adds an :mod:`abc` module that lets you define Abstract Base Classes |
| 680 | (ABCs). You can then use :func:`isinstance` and :func:`issubclass` to check |
| 681 | whether an instance or a class implements a particular ABC. The |
| 682 | :mod:`collections` modules defines a set of useful ABCs such as |
| 683 | :class:`Iterable`, :class:`Container`, and :class:`MutableMapping`. |
| 684 | |
| 685 | For Python, many of the advantages of interface specifications can be obtained |
| 686 | by an appropriate test discipline for components. There is also a tool, |
| 687 | PyChecker, which can be used to find problems due to subclassing. |
| 688 | |
| 689 | A good test suite for a module can both provide a regression test and serve as a |
| 690 | module interface specification and a set of examples. Many Python modules can |
| 691 | be run as a script to provide a simple "self test." Even modules which use |
| 692 | complex external interfaces can often be tested in isolation using trivial |
| 693 | "stub" emulations of the external interface. The :mod:`doctest` and |
| 694 | :mod:`unittest` modules or third-party test frameworks can be used to construct |
| 695 | exhaustive test suites that exercise every line of code in a module. |
| 696 | |
| 697 | An appropriate testing discipline can help build large complex applications in |
| 698 | Python as well as having interface specifications would. In fact, it can be |
| 699 | better because an interface specification cannot test certain properties of a |
| 700 | program. For example, the :meth:`append` method is expected to add new elements |
| 701 | to the end of some internal list; an interface specification cannot test that |
| 702 | your :meth:`append` implementation will actually do this correctly, but it's |
| 703 | trivial to check this property in a test suite. |
| 704 | |
| 705 | Writing test suites is very helpful, and you might want to design your code with |
| 706 | an eye to making it easily tested. One increasingly popular technique, |
| 707 | test-directed development, calls for writing parts of the test suite first, |
| 708 | before you write any of the actual code. Of course Python allows you to be |
| 709 | sloppy and not write test cases at all. |
| 710 | |
| 711 | |
| 712 | Why are default values shared between objects? |
| 713 | ---------------------------------------------- |
| 714 | |
| 715 | This type of bug commonly bites neophyte programmers. Consider this function:: |
| 716 | |
| 717 | def foo(D={}): # Danger: shared reference to one dict for all calls |
| 718 | ... compute something ... |
| 719 | D[key] = value |
| 720 | return D |
| 721 | |
| 722 | The first time you call this function, ``D`` contains a single item. The second |
| 723 | time, ``D`` contains two items because when ``foo()`` begins executing, ``D`` |
| 724 | starts out with an item already in it. |
| 725 | |
| 726 | It is often expected that a function call creates new objects for default |
| 727 | values. This is not what happens. Default values are created exactly once, when |
| 728 | the function is defined. If that object is changed, like the dictionary in this |
| 729 | example, subsequent calls to the function will refer to this changed object. |
| 730 | |
| 731 | By definition, immutable objects such as numbers, strings, tuples, and ``None``, |
| 732 | are safe from change. Changes to mutable objects such as dictionaries, lists, |
| 733 | and class instances can lead to confusion. |
| 734 | |
| 735 | Because of this feature, it is good programming practice to not use mutable |
| 736 | objects as default values. Instead, use ``None`` as the default value and |
| 737 | inside the function, check if the parameter is ``None`` and create a new |
| 738 | list/dictionary/whatever if it is. For example, don't write:: |
| 739 | |
| 740 | def foo(dict={}): |
| 741 | ... |
| 742 | |
| 743 | but:: |
| 744 | |
| 745 | def foo(dict=None): |
| 746 | if dict is None: |
| 747 | dict = {} # create a new dict for local namespace |
| 748 | |
| 749 | This feature can be useful. When you have a function that's time-consuming to |
| 750 | compute, a common technique is to cache the parameters and the resulting value |
| 751 | of each call to the function, and return the cached value if the same value is |
| 752 | requested again. This is called "memoizing", and can be implemented like this:: |
| 753 | |
| 754 | # Callers will never provide a third parameter for this function. |
| 755 | def expensive (arg1, arg2, _cache={}): |
Georg Brandl | bfe95ac | 2009-12-19 17:46:40 +0000 | [diff] [blame^] | 756 | if (arg1, arg2) in _cache: |
Georg Brandl | d741315 | 2009-10-11 21:25:26 +0000 | [diff] [blame] | 757 | return _cache[(arg1, arg2)] |
| 758 | |
| 759 | # Calculate the value |
| 760 | result = ... expensive computation ... |
| 761 | _cache[(arg1, arg2)] = result # Store result in the cache |
| 762 | return result |
| 763 | |
| 764 | You could use a global variable containing a dictionary instead of the default |
| 765 | value; it's a matter of taste. |
| 766 | |
| 767 | |
| 768 | Why is there no goto? |
| 769 | --------------------- |
| 770 | |
| 771 | You can use exceptions to provide a "structured goto" that even works across |
| 772 | function calls. Many feel that exceptions can conveniently emulate all |
| 773 | reasonable uses of the "go" or "goto" constructs of C, Fortran, and other |
| 774 | languages. For example:: |
| 775 | |
| 776 | class label: pass # declare a label |
| 777 | |
| 778 | try: |
| 779 | ... |
| 780 | if (condition): raise label() # goto label |
| 781 | ... |
| 782 | except label: # where to goto |
| 783 | pass |
| 784 | ... |
| 785 | |
| 786 | This doesn't allow you to jump into the middle of a loop, but that's usually |
| 787 | considered an abuse of goto anyway. Use sparingly. |
| 788 | |
| 789 | |
| 790 | Why can't raw strings (r-strings) end with a backslash? |
| 791 | ------------------------------------------------------- |
| 792 | |
| 793 | More precisely, they can't end with an odd number of backslashes: the unpaired |
| 794 | backslash at the end escapes the closing quote character, leaving an |
| 795 | unterminated string. |
| 796 | |
| 797 | Raw strings were designed to ease creating input for processors (chiefly regular |
| 798 | expression engines) that want to do their own backslash escape processing. Such |
| 799 | processors consider an unmatched trailing backslash to be an error anyway, so |
| 800 | raw strings disallow that. In return, they allow you to pass on the string |
| 801 | quote character by escaping it with a backslash. These rules work well when |
| 802 | r-strings are used for their intended purpose. |
| 803 | |
| 804 | If you're trying to build Windows pathnames, note that all Windows system calls |
| 805 | accept forward slashes too:: |
| 806 | |
| 807 | f = open("/mydir/file.txt") # works fine! |
| 808 | |
| 809 | If you're trying to build a pathname for a DOS command, try e.g. one of :: |
| 810 | |
| 811 | dir = r"\this\is\my\dos\dir" "\\" |
| 812 | dir = r"\this\is\my\dos\dir\ "[:-1] |
| 813 | dir = "\\this\\is\\my\\dos\\dir\\" |
| 814 | |
| 815 | |
| 816 | Why doesn't Python have a "with" statement for attribute assignments? |
| 817 | --------------------------------------------------------------------- |
| 818 | |
| 819 | Python has a 'with' statement that wraps the execution of a block, calling code |
| 820 | on the entrance and exit from the block. Some language have a construct that |
| 821 | looks like this:: |
| 822 | |
| 823 | with obj: |
| 824 | a = 1 # equivalent to obj.a = 1 |
| 825 | total = total + 1 # obj.total = obj.total + 1 |
| 826 | |
| 827 | In Python, such a construct would be ambiguous. |
| 828 | |
| 829 | Other languages, such as Object Pascal, Delphi, and C++, use static types, so |
| 830 | it's possible to know, in an unambiguous way, what member is being assigned |
| 831 | to. This is the main point of static typing -- the compiler *always* knows the |
| 832 | scope of every variable at compile time. |
| 833 | |
| 834 | Python uses dynamic types. It is impossible to know in advance which attribute |
| 835 | will be referenced at runtime. Member attributes may be added or removed from |
| 836 | objects on the fly. This makes it impossible to know, from a simple reading, |
| 837 | what attribute is being referenced: a local one, a global one, or a member |
| 838 | attribute? |
| 839 | |
| 840 | For instance, take the following incomplete snippet:: |
| 841 | |
| 842 | def foo(a): |
| 843 | with a: |
| 844 | print x |
| 845 | |
| 846 | The snippet assumes that "a" must have a member attribute called "x". However, |
| 847 | there is nothing in Python that tells the interpreter this. What should happen |
| 848 | if "a" is, let us say, an integer? If there is a global variable named "x", |
| 849 | will it be used inside the with block? As you see, the dynamic nature of Python |
| 850 | makes such choices much harder. |
| 851 | |
| 852 | The primary benefit of "with" and similar language features (reduction of code |
| 853 | volume) can, however, easily be achieved in Python by assignment. Instead of:: |
| 854 | |
| 855 | function(args).dict[index][index].a = 21 |
| 856 | function(args).dict[index][index].b = 42 |
| 857 | function(args).dict[index][index].c = 63 |
| 858 | |
| 859 | write this:: |
| 860 | |
| 861 | ref = function(args).dict[index][index] |
| 862 | ref.a = 21 |
| 863 | ref.b = 42 |
| 864 | ref.c = 63 |
| 865 | |
| 866 | This also has the side-effect of increasing execution speed because name |
| 867 | bindings are resolved at run-time in Python, and the second version only needs |
| 868 | to perform the resolution once. If the referenced object does not have a, b and |
| 869 | c attributes, of course, the end result is still a run-time exception. |
| 870 | |
| 871 | |
| 872 | Why are colons required for the if/while/def/class statements? |
| 873 | -------------------------------------------------------------- |
| 874 | |
| 875 | The colon is required primarily to enhance readability (one of the results of |
| 876 | the experimental ABC language). Consider this:: |
| 877 | |
| 878 | if a == b |
| 879 | print a |
| 880 | |
| 881 | versus :: |
| 882 | |
| 883 | if a == b: |
| 884 | print a |
| 885 | |
| 886 | Notice how the second one is slightly easier to read. Notice further how a |
| 887 | colon sets off the example in this FAQ answer; it's a standard usage in English. |
| 888 | |
| 889 | Another minor reason is that the colon makes it easier for editors with syntax |
| 890 | highlighting; they can look for colons to decide when indentation needs to be |
| 891 | increased instead of having to do a more elaborate parsing of the program text. |
| 892 | |
| 893 | |
| 894 | Why does Python allow commas at the end of lists and tuples? |
| 895 | ------------------------------------------------------------ |
| 896 | |
| 897 | Python lets you add a trailing comma at the end of lists, tuples, and |
| 898 | dictionaries:: |
| 899 | |
| 900 | [1, 2, 3,] |
| 901 | ('a', 'b', 'c',) |
| 902 | d = { |
| 903 | "A": [1, 5], |
| 904 | "B": [6, 7], # last trailing comma is optional but good style |
| 905 | } |
| 906 | |
| 907 | |
| 908 | There are several reasons to allow this. |
| 909 | |
| 910 | When you have a literal value for a list, tuple, or dictionary spread across |
| 911 | multiple lines, it's easier to add more elements because you don't have to |
| 912 | remember to add a comma to the previous line. The lines can also be sorted in |
| 913 | your editor without creating a syntax error. |
| 914 | |
| 915 | Accidentally omitting the comma can lead to errors that are hard to diagnose. |
| 916 | For example:: |
| 917 | |
| 918 | x = [ |
| 919 | "fee", |
| 920 | "fie" |
| 921 | "foo", |
| 922 | "fum" |
| 923 | ] |
| 924 | |
| 925 | This list looks like it has four elements, but it actually contains three: |
| 926 | "fee", "fiefoo" and "fum". Always adding the comma avoids this source of error. |
| 927 | |
| 928 | Allowing the trailing comma may also make programmatic code generation easier. |