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