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