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