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   functions = {'a': function_1,
270                'b': function_2,
271                'c': self.method_1}
272
273   func = functions[value]
274   func()
275
276For calling methods on objects, you can simplify yet further by using the
277:func:`getattr` built-in to retrieve methods with a particular name::
278
279   class MyVisitor:
280       def visit_a(self):
281           ...
282
283       def dispatch(self, value):
284           method_name = 'visit_' + str(value)
285           method = getattr(self, method_name)
286           method()
287
288It's suggested that you use a prefix for the method names, such as ``visit_`` in
289this example.  Without such a prefix, if values are coming from an untrusted
290source, an attacker would be able to call any method on your object.
291
292
293Can't you emulate threads in the interpreter instead of relying on an OS-specific thread implementation?
294--------------------------------------------------------------------------------------------------------
295
296Answer 1: Unfortunately, the interpreter pushes at least one C stack frame for
297each Python stack frame.  Also, extensions can call back into Python at almost
298random moments.  Therefore, a complete threads implementation requires thread
299support for C.
300
301Answer 2: Fortunately, there is `Stackless Python <https://github.com/stackless-dev/stackless/wiki>`_,
302which has a completely redesigned interpreter loop that avoids the C stack.
303
304
305Why can't lambda expressions contain statements?
306------------------------------------------------
307
308Python lambda expressions cannot contain statements because Python's syntactic
309framework can't handle statements nested inside expressions.  However, in
310Python, this is not a serious problem.  Unlike lambda forms in other languages,
311where they add functionality, Python lambdas are only a shorthand notation if
312you're too lazy to define a function.
313
314Functions are already first class objects in Python, and can be declared in a
315local scope.  Therefore the only advantage of using a lambda instead of a
316locally defined function is that you don't need to invent a name for the
317function -- but that's just a local variable to which the function object (which
318is exactly the same type of object that a lambda expression yields) is assigned!
319
320
321Can Python be compiled to machine code, C or some other language?
322-----------------------------------------------------------------
323
324`Cython <https://cython.org/>`_ compiles a modified version of Python with
325optional annotations into C extensions.  `Nuitka <https://www.nuitka.net/>`_ is
326an up-and-coming compiler of Python into C++ code, aiming to support the full
327Python language.
328
329
330How does Python manage memory?
331------------------------------
332
333The details of Python memory management depend on the implementation.  The
334standard implementation of Python, :term:`CPython`, uses reference counting to
335detect inaccessible objects, and another mechanism to collect reference cycles,
336periodically executing a cycle detection algorithm which looks for inaccessible
337cycles and deletes the objects involved. The :mod:`gc` module provides functions
338to perform a garbage collection, obtain debugging statistics, and tune the
339collector's parameters.
340
341Other implementations (such as `Jython <https://www.jython.org>`_ or
342`PyPy <https://www.pypy.org>`_), however, can rely on a different mechanism
343such as a full-blown garbage collector.  This difference can cause some
344subtle porting problems if your Python code depends on the behavior of the
345reference counting implementation.
346
347In some Python implementations, the following code (which is fine in CPython)
348will probably run out of file descriptors::
349
350   for file in very_long_list_of_files:
351       f = open(file)
352       c = f.read(1)
353
354Indeed, using CPython's reference counting and destructor scheme, each new
355assignment to *f* closes the previous file.  With a traditional GC, however,
356those file objects will only get collected (and closed) at varying and possibly
357long intervals.
358
359If you want to write code that will work with any Python implementation,
360you should explicitly close the file or use the :keyword:`with` statement;
361this will work regardless of memory management scheme::
362
363   for file in very_long_list_of_files:
364       with open(file) as f:
365           c = f.read(1)
366
367
368Why doesn't CPython use a more traditional garbage collection scheme?
369---------------------------------------------------------------------
370
371For one thing, this is not a C standard feature and hence it's not portable.
372(Yes, we know about the Boehm GC library.  It has bits of assembler code for
373*most* common platforms, not for all of them, and although it is mostly
374transparent, it isn't completely transparent; patches are required to get
375Python to work with it.)
376
377Traditional GC also becomes a problem when Python is embedded into other
378applications.  While in a standalone Python it's fine to replace the standard
379malloc() and free() with versions provided by the GC library, an application
380embedding Python may want to have its *own* substitute for malloc() and free(),
381and may not want Python's.  Right now, CPython works with anything that
382implements malloc() and free() properly.
383
384
385Why isn't all memory freed when CPython exits?
386----------------------------------------------
387
388Objects referenced from the global namespaces of Python modules are not always
389deallocated when Python exits.  This may happen if there are circular
390references.  There are also certain bits of memory that are allocated by the C
391library that are impossible to free (e.g. a tool like Purify will complain about
392these).  Python is, however, aggressive about cleaning up memory on exit and
393does try to destroy every single object.
394
395If you want to force Python to delete certain things on deallocation use the
396:mod:`atexit` module to run a function that will force those deletions.
397
398
399Why are there separate tuple and list data types?
400-------------------------------------------------
401
402Lists and tuples, while similar in many respects, are generally used in
403fundamentally different ways.  Tuples can be thought of as being similar to
404Pascal records or C structs; they're small collections of related data which may
405be of different types which are operated on as a group.  For example, a
406Cartesian coordinate is appropriately represented as a tuple of two or three
407numbers.
408
409Lists, on the other hand, are more like arrays in other languages.  They tend to
410hold a varying number of objects all of which have the same type and which are
411operated on one-by-one.  For example, ``os.listdir('.')`` returns a list of
412strings representing the files in the current directory.  Functions which
413operate on this output would generally not break if you added another file or
414two to the directory.
415
416Tuples are immutable, meaning that once a tuple has been created, you can't
417replace any of its elements with a new value.  Lists are mutable, meaning that
418you can always change a list's elements.  Only immutable elements can be used as
419dictionary keys, and hence only tuples and not lists can be used as keys.
420
421
422How are lists implemented in CPython?
423-------------------------------------
424
425CPython's lists are really variable-length arrays, not Lisp-style linked lists.
426The implementation uses a contiguous array of references to other objects, and
427keeps a pointer to this array and the array's length in a list head structure.
428
429This makes indexing a list ``a[i]`` an operation whose cost is independent of
430the size of the list or the value of the index.
431
432When items are appended or inserted, the array of references is resized.  Some
433cleverness is applied to improve the performance of appending items repeatedly;
434when the array must be grown, some extra space is allocated so the next few
435times don't require an actual resize.
436
437
438How are dictionaries implemented in CPython?
439--------------------------------------------
440
441CPython's dictionaries are implemented as resizable hash tables.  Compared to
442B-trees, this gives better performance for lookup (the most common operation by
443far) under most circumstances, and the implementation is simpler.
444
445Dictionaries work by computing a hash code for each key stored in the dictionary
446using the :func:`hash` built-in function.  The hash code varies widely depending
447on the key and a per-process seed; for example, "Python" could hash to
448-539294296 while "python", a string that differs by a single bit, could hash
449to 1142331976.  The hash code is then used to calculate a location in an
450internal array where the value will be stored.  Assuming that you're storing
451keys that all have different hash values, this means that dictionaries take
452constant time -- O(1), in Big-O notation -- to retrieve a key.
453
454
455Why must dictionary keys be immutable?
456--------------------------------------
457
458The hash table implementation of dictionaries uses a hash value calculated from
459the key value to find the key.  If the key were a mutable object, its value
460could change, and thus its hash could also change.  But since whoever changes
461the key object can't tell that it was being used as a dictionary key, it can't
462move the entry around in the dictionary.  Then, when you try to look up the same
463object in the dictionary it won't be found because its hash value is different.
464If you tried to look up the old value it wouldn't be found either, because the
465value of the object found in that hash bin would be different.
466
467If you want a dictionary indexed with a list, simply convert the list to a tuple
468first; the function ``tuple(L)`` creates a tuple with the same entries as the
469list ``L``.  Tuples are immutable and can therefore be used as dictionary keys.
470
471Some unacceptable solutions that have been proposed:
472
473- Hash lists by their address (object ID).  This doesn't work because if you
474  construct a new list with the same value it won't be found; e.g.::
475
476     mydict = {[1, 2]: '12'}
477     print(mydict[[1, 2]])
478
479  would raise a :exc:`KeyError` exception because the id of the ``[1, 2]`` used in the
480  second line differs from that in the first line.  In other words, dictionary
481  keys should be compared using ``==``, not using :keyword:`is`.
482
483- Make a copy when using a list as a key.  This doesn't work because the list,
484  being a mutable object, could contain a reference to itself, and then the
485  copying code would run into an infinite loop.
486
487- Allow lists as keys but tell the user not to modify them.  This would allow a
488  class of hard-to-track bugs in programs when you forgot or modified a list by
489  accident. It also invalidates an important invariant of dictionaries: every
490  value in ``d.keys()`` is usable as a key of the dictionary.
491
492- Mark lists as read-only once they are used as a dictionary key.  The problem
493  is that it's not just the top-level object that could change its value; you
494  could use a tuple containing a list as a key.  Entering anything as a key into
495  a dictionary would require marking all objects reachable from there as
496  read-only -- and again, self-referential objects could cause an infinite loop.
497
498There is a trick to get around this if you need to, but use it at your own risk:
499You can wrap a mutable structure inside a class instance which has both a
500:meth:`__eq__` and a :meth:`__hash__` method.  You must then make sure that the
501hash value for all such wrapper objects that reside in a dictionary (or other
502hash based structure), remain fixed while the object is in the dictionary (or
503other structure). ::
504
505   class ListWrapper:
506       def __init__(self, the_list):
507           self.the_list = the_list
508
509       def __eq__(self, other):
510           return self.the_list == other.the_list
511
512       def __hash__(self):
513           l = self.the_list
514           result = 98767 - len(l)*555
515           for i, el in enumerate(l):
516               try:
517                   result = result + (hash(el) % 9999999) * 1001 + i
518               except Exception:
519                   result = (result % 7777777) + i * 333
520           return result
521
522Note that the hash computation is complicated by the possibility that some
523members of the list may be unhashable and also by the possibility of arithmetic
524overflow.
525
526Furthermore it must always be the case that if ``o1 == o2`` (ie ``o1.__eq__(o2)
527is True``) then ``hash(o1) == hash(o2)`` (ie, ``o1.__hash__() == o2.__hash__()``),
528regardless of whether the object is in a dictionary or not.  If you fail to meet
529these restrictions dictionaries and other hash based structures will misbehave.
530
531In the case of ListWrapper, whenever the wrapper object is in a dictionary the
532wrapped list must not change to avoid anomalies.  Don't do this unless you are
533prepared to think hard about the requirements and the consequences of not
534meeting them correctly.  Consider yourself warned.
535
536
537Why doesn't list.sort() return the sorted list?
538-----------------------------------------------
539
540In situations where performance matters, making a copy of the list just to sort
541it would be wasteful. Therefore, :meth:`list.sort` sorts the list in place. In
542order to remind you of that fact, it does not return the sorted list.  This way,
543you won't be fooled into accidentally overwriting a list when you need a sorted
544copy but also need to keep the unsorted version around.
545
546If you want to return a new list, use the built-in :func:`sorted` function
547instead.  This function creates a new list from a provided iterable, sorts
548it and returns it.  For example, here's how to iterate over the keys of a
549dictionary in sorted order::
550
551   for key in sorted(mydict):
552       ...  # do whatever with mydict[key]...
553
554
555How do you specify and enforce an interface spec in Python?
556-----------------------------------------------------------
557
558An interface specification for a module as provided by languages such as C++ and
559Java describes the prototypes for the methods and functions of the module.  Many
560feel that compile-time enforcement of interface specifications helps in the
561construction of large programs.
562
563Python 2.6 adds an :mod:`abc` module that lets you define Abstract Base Classes
564(ABCs).  You can then use :func:`isinstance` and :func:`issubclass` to check
565whether an instance or a class implements a particular ABC.  The
566:mod:`collections.abc` module defines a set of useful ABCs such as
567:class:`~collections.abc.Iterable`, :class:`~collections.abc.Container`, and
568:class:`~collections.abc.MutableMapping`.
569
570For Python, many of the advantages of interface specifications can be obtained
571by an appropriate test discipline for components.
572
573A good test suite for a module can both provide a regression test and serve as a
574module interface specification and a set of examples.  Many Python modules can
575be run as a script to provide a simple "self test."  Even modules which use
576complex external interfaces can often be tested in isolation using trivial
577"stub" emulations of the external interface.  The :mod:`doctest` and
578:mod:`unittest` modules or third-party test frameworks can be used to construct
579exhaustive test suites that exercise every line of code in a module.
580
581An appropriate testing discipline can help build large complex applications in
582Python as well as having interface specifications would.  In fact, it can be
583better because an interface specification cannot test certain properties of a
584program.  For example, the :meth:`append` method is expected to add new elements
585to the end of some internal list; an interface specification cannot test that
586your :meth:`append` implementation will actually do this correctly, but it's
587trivial to check this property in a test suite.
588
589Writing test suites is very helpful, and you might want to design your code to
590make it easily tested. One increasingly popular technique, test-driven
591development, calls for writing parts of the test suite first, before you write
592any of the actual code.  Of course Python allows you to be sloppy and not write
593test cases at all.
594
595
596Why is there no goto?
597---------------------
598
599In the 1970s people realized that unrestricted goto could lead
600to messy "spaghetti" code that was hard to understand and revise.
601In a high-level language, it is also unneeded as long as there
602are ways to branch (in Python, with ``if`` statements and ``or``,
603``and``, and ``if-else`` expressions) and loop (with ``while``
604and ``for`` statements, possibly containing ``continue`` and ``break``).
605
606One can also use exceptions to provide a "structured goto"
607that works even across
608function calls.  Many feel that exceptions can conveniently emulate all
609reasonable uses of the "go" or "goto" constructs of C, Fortran, and other
610languages.  For example::
611
612   class label(Exception): pass  # declare a label
613
614   try:
615       ...
616       if condition: raise label()  # goto label
617       ...
618   except label:  # where to goto
619       pass
620   ...
621
622This doesn't allow you to jump into the middle of a loop, but that's usually
623considered an abuse of goto anyway.  Use sparingly.
624
625
626Why can't raw strings (r-strings) end with a backslash?
627-------------------------------------------------------
628
629More precisely, they can't end with an odd number of backslashes: the unpaired
630backslash at the end escapes the closing quote character, leaving an
631unterminated string.
632
633Raw strings were designed to ease creating input for processors (chiefly regular
634expression engines) that want to do their own backslash escape processing. Such
635processors consider an unmatched trailing backslash to be an error anyway, so
636raw strings disallow that.  In return, they allow you to pass on the string
637quote character by escaping it with a backslash.  These rules work well when
638r-strings are used for their intended purpose.
639
640If you're trying to build Windows pathnames, note that all Windows system calls
641accept forward slashes too::
642
643   f = open("/mydir/file.txt")  # works fine!
644
645If you're trying to build a pathname for a DOS command, try e.g. one of ::
646
647   dir = r"\this\is\my\dos\dir" "\\"
648   dir = r"\this\is\my\dos\dir\ "[:-1]
649   dir = "\\this\\is\\my\\dos\\dir\\"
650
651
652Why doesn't Python have a "with" statement for attribute assignments?
653---------------------------------------------------------------------
654
655Python has a 'with' statement that wraps the execution of a block, calling code
656on the entrance and exit from the block.  Some languages have a construct that
657looks like this::
658
659   with obj:
660       a = 1               # equivalent to obj.a = 1
661       total = total + 1   # obj.total = obj.total + 1
662
663In Python, such a construct would be ambiguous.
664
665Other languages, such as Object Pascal, Delphi, and C++, use static types, so
666it's possible to know, in an unambiguous way, what member is being assigned
667to. This is the main point of static typing -- the compiler *always* knows the
668scope of every variable at compile time.
669
670Python uses dynamic types. It is impossible to know in advance which attribute
671will be referenced at runtime. Member attributes may be added or removed from
672objects on the fly. This makes it impossible to know, from a simple reading,
673what attribute is being referenced: a local one, a global one, or a member
674attribute?
675
676For instance, take the following incomplete snippet::
677
678   def foo(a):
679       with a:
680           print(x)
681
682The snippet assumes that "a" must have a member attribute called "x".  However,
683there is nothing in Python that tells the interpreter this. What should happen
684if "a" is, let us say, an integer?  If there is a global variable named "x",
685will it be used inside the with block?  As you see, the dynamic nature of Python
686makes such choices much harder.
687
688The primary benefit of "with" and similar language features (reduction of code
689volume) can, however, easily be achieved in Python by assignment.  Instead of::
690
691   function(args).mydict[index][index].a = 21
692   function(args).mydict[index][index].b = 42
693   function(args).mydict[index][index].c = 63
694
695write this::
696
697   ref = function(args).mydict[index][index]
698   ref.a = 21
699   ref.b = 42
700   ref.c = 63
701
702This also has the side-effect of increasing execution speed because name
703bindings are resolved at run-time in Python, and the second version only needs
704to perform the resolution once.
705
706
707Why don't generators support the with statement?
708------------------------------------------------
709
710For technical reasons, a generator used directly as a context manager
711would not work correctly.  When, as is most common, a generator is used as
712an iterator run to completion, no closing is needed.  When it is, wrap
713it as "contextlib.closing(generator)" in the 'with' statement.
714
715
716Why are colons required for the if/while/def/class statements?
717--------------------------------------------------------------
718
719The colon is required primarily to enhance readability (one of the results of
720the experimental ABC language).  Consider this::
721
722   if a == b
723       print(a)
724
725versus ::
726
727   if a == b:
728       print(a)
729
730Notice how the second one is slightly easier to read.  Notice further how a
731colon sets off the example in this FAQ answer; it's a standard usage in English.
732
733Another minor reason is that the colon makes it easier for editors with syntax
734highlighting; they can look for colons to decide when indentation needs to be
735increased instead of having to do a more elaborate parsing of the program text.
736
737
738Why does Python allow commas at the end of lists and tuples?
739------------------------------------------------------------
740
741Python lets you add a trailing comma at the end of lists, tuples, and
742dictionaries::
743
744   [1, 2, 3,]
745   ('a', 'b', 'c',)
746   d = {
747       "A": [1, 5],
748       "B": [6, 7],  # last trailing comma is optional but good style
749   }
750
751
752There are several reasons to allow this.
753
754When you have a literal value for a list, tuple, or dictionary spread across
755multiple lines, it's easier to add more elements because you don't have to
756remember to add a comma to the previous line.  The lines can also be reordered
757without creating a syntax error.
758
759Accidentally omitting the comma can lead to errors that are hard to diagnose.
760For example::
761
762       x = [
763         "fee",
764         "fie"
765         "foo",
766         "fum"
767       ]
768
769This list looks like it has four elements, but it actually contains three:
770"fee", "fiefoo" and "fum".  Always adding the comma avoids this source of error.
771
772Allowing the trailing comma may also make programmatic code generation easier.
773