Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1 | |
| 2 | .. _simple: |
| 3 | |
| 4 | ***************** |
| 5 | Simple statements |
| 6 | ***************** |
| 7 | |
| 8 | .. index:: pair: simple; statement |
| 9 | |
| 10 | Simple statements are comprised within a single logical line. Several simple |
| 11 | statements may occur on a single line separated by semicolons. The syntax for |
| 12 | simple statements is: |
| 13 | |
| 14 | .. productionlist:: |
| 15 | simple_stmt: `expression_stmt` |
| 16 | : | `assert_stmt` |
| 17 | : | `assignment_stmt` |
| 18 | : | `augmented_assignment_stmt` |
| 19 | : | `pass_stmt` |
| 20 | : | `del_stmt` |
| 21 | : | `return_stmt` |
| 22 | : | `yield_stmt` |
| 23 | : | `raise_stmt` |
| 24 | : | `break_stmt` |
| 25 | : | `continue_stmt` |
| 26 | : | `import_stmt` |
| 27 | : | `global_stmt` |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 28 | : | `nonlocal_stmt` |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 29 | |
| 30 | |
| 31 | .. _exprstmts: |
| 32 | |
| 33 | Expression statements |
| 34 | ===================== |
| 35 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 36 | .. index:: |
| 37 | pair: expression; statement |
| 38 | pair: expression; list |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 39 | .. index:: pair: expression; list |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 40 | |
| 41 | Expression statements are used (mostly interactively) to compute and write a |
| 42 | value, or (usually) to call a procedure (a function that returns no meaningful |
| 43 | result; in Python, procedures return the value ``None``). Other uses of |
| 44 | expression statements are allowed and occasionally useful. The syntax for an |
| 45 | expression statement is: |
| 46 | |
| 47 | .. productionlist:: |
| 48 | expression_stmt: `expression_list` |
| 49 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 50 | An expression statement evaluates the expression list (which may be a single |
| 51 | expression). |
| 52 | |
| 53 | .. index:: |
| 54 | builtin: repr |
| 55 | object: None |
| 56 | pair: string; conversion |
| 57 | single: output |
| 58 | pair: standard; output |
| 59 | pair: writing; values |
| 60 | pair: procedure; call |
| 61 | |
| 62 | In interactive mode, if the value is not ``None``, it is converted to a string |
| 63 | using the built-in :func:`repr` function and the resulting string is written to |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 64 | standard output on a line by itself (except if the result is ``None``, so that |
| 65 | procedure calls do not cause any output.) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 66 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 67 | .. _assignment: |
| 68 | |
| 69 | Assignment statements |
| 70 | ===================== |
| 71 | |
| 72 | .. index:: |
| 73 | pair: assignment; statement |
| 74 | pair: binding; name |
| 75 | pair: rebinding; name |
| 76 | object: mutable |
| 77 | pair: attribute; assignment |
| 78 | |
| 79 | Assignment statements are used to (re)bind names to values and to modify |
| 80 | attributes or items of mutable objects: |
| 81 | |
| 82 | .. productionlist:: |
| 83 | assignment_stmt: (`target_list` "=")+ (`expression_list` | `yield_expression`) |
| 84 | target_list: `target` ("," `target`)* [","] |
| 85 | target: `identifier` |
| 86 | : | "(" `target_list` ")" |
| 87 | : | "[" `target_list` "]" |
| 88 | : | `attributeref` |
| 89 | : | `subscription` |
| 90 | : | `slicing` |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 91 | : | "*" `target` |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 92 | |
| 93 | (See section :ref:`primaries` for the syntax definitions for the last three |
| 94 | symbols.) |
| 95 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 96 | An assignment statement evaluates the expression list (remember that this can be |
| 97 | a single expression or a comma-separated list, the latter yielding a tuple) and |
| 98 | assigns the single resulting object to each of the target lists, from left to |
| 99 | right. |
| 100 | |
| 101 | .. index:: |
| 102 | single: target |
| 103 | pair: target; list |
| 104 | |
| 105 | Assignment is defined recursively depending on the form of the target (list). |
| 106 | When a target is part of a mutable object (an attribute reference, subscription |
| 107 | or slicing), the mutable object must ultimately perform the assignment and |
| 108 | decide about its validity, and may raise an exception if the assignment is |
| 109 | unacceptable. The rules observed by various types and the exceptions raised are |
| 110 | given with the definition of the object types (see section :ref:`types`). |
| 111 | |
| 112 | .. index:: triple: target; list; assignment |
| 113 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 114 | Assignment of an object to a target list, optionally enclosed in parentheses or |
| 115 | square brackets, is recursively defined as follows. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 116 | |
| 117 | * If the target list is a single target: The object is assigned to that target. |
| 118 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 119 | * If the target list is a comma-separated list of targets: |
| 120 | |
| 121 | * If the target list contains one target prefixed with an asterisk, called a |
| 122 | "starred" target: The object must be a sequence with at least as many items |
| 123 | as there are targets in the target list, minus one. The first items of the |
| 124 | sequence are assigned, from left to right, to the targets before the starred |
| 125 | target. The final items of the sequence are assigned to the targets after |
| 126 | the starred target. A list of the remaining items in the sequence is then |
| 127 | assigned to the starred target (the list can be empty). |
| 128 | |
| 129 | * Else: The object must be a sequence with the same number of items as there |
| 130 | are targets in the target list, and the items are assigned, from left to |
| 131 | right, to the corresponding targets. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 132 | |
| 133 | Assignment of an object to a single target is recursively defined as follows. |
| 134 | |
| 135 | * If the target is an identifier (name): |
| 136 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 137 | * If the name does not occur in a :keyword:`global` or :keyword:`nonlocal` |
| 138 | statement in the current code block: the name is bound to the object in the |
| 139 | current local namespace. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 140 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 141 | * Otherwise: the name is bound to the object in the global namespace or the |
| 142 | outer namespace determined by :keyword:`nonlocal`, respectively. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 143 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 144 | The name is rebound if it was already bound. This may cause the reference |
| 145 | count for the object previously bound to the name to reach zero, causing the |
| 146 | object to be deallocated and its destructor (if it has one) to be called. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 147 | |
Christian Heimes | 5b5e81c | 2007-12-31 16:14:33 +0000 | [diff] [blame] | 148 | .. index:: single: destructor |
| 149 | |
| 150 | The name is rebound if it was already bound. This may cause the reference count |
| 151 | for the object previously bound to the name to reach zero, causing the object to |
| 152 | be deallocated and its destructor (if it has one) to be called. |
| 153 | |
| 154 | * If the target is a target list enclosed in parentheses or in square brackets: |
| 155 | The object must be a sequence with the same number of items as there are targets |
| 156 | in the target list, and its items are assigned, from left to right, to the |
| 157 | corresponding targets. |
| 158 | |
| 159 | .. index:: pair: attribute; assignment |
| 160 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 161 | * If the target is an attribute reference: The primary expression in the |
| 162 | reference is evaluated. It should yield an object with assignable attributes; |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 163 | if this is not the case, :exc:`TypeError` is raised. That object is then |
| 164 | asked to assign the assigned object to the given attribute; if it cannot |
| 165 | perform the assignment, it raises an exception (usually but not necessarily |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 166 | :exc:`AttributeError`). |
| 167 | |
| 168 | .. index:: |
| 169 | pair: subscription; assignment |
| 170 | object: mutable |
| 171 | |
| 172 | * If the target is a subscription: The primary expression in the reference is |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 173 | evaluated. It should yield either a mutable sequence object (such as a list) |
| 174 | or a mapping object (such as a dictionary). Next, the subscript expression is |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 175 | evaluated. |
| 176 | |
| 177 | .. index:: |
| 178 | object: sequence |
| 179 | object: list |
| 180 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 181 | If the primary is a mutable sequence object (such as a list), the subscript |
| 182 | must yield an integer. If it is negative, the sequence's length is added to |
| 183 | it. The resulting value must be a nonnegative integer less than the |
| 184 | sequence's length, and the sequence is asked to assign the assigned object to |
| 185 | its item with that index. If the index is out of range, :exc:`IndexError` is |
| 186 | raised (assignment to a subscripted sequence cannot add new items to a list). |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 187 | |
| 188 | .. index:: |
| 189 | object: mapping |
| 190 | object: dictionary |
| 191 | |
| 192 | If the primary is a mapping object (such as a dictionary), the subscript must |
| 193 | have a type compatible with the mapping's key type, and the mapping is then |
| 194 | asked to create a key/datum pair which maps the subscript to the assigned |
| 195 | object. This can either replace an existing key/value pair with the same key |
| 196 | value, or insert a new key/value pair (if no key with the same value existed). |
| 197 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 198 | For user-defined objects, the :meth:`__setitem__` method is called with |
| 199 | appropriate arguments. |
| 200 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 201 | .. index:: pair: slicing; assignment |
| 202 | |
| 203 | * If the target is a slicing: The primary expression in the reference is |
| 204 | evaluated. It should yield a mutable sequence object (such as a list). The |
| 205 | assigned object should be a sequence object of the same type. Next, the lower |
| 206 | and upper bound expressions are evaluated, insofar they are present; defaults |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 207 | are zero and the sequence's length. The bounds should evaluate to integers. |
| 208 | If either bound is negative, the sequence's length is added to it. The |
| 209 | resulting bounds are clipped to lie between zero and the sequence's length, |
| 210 | inclusive. Finally, the sequence object is asked to replace the slice with |
| 211 | the items of the assigned sequence. The length of the slice may be different |
| 212 | from the length of the assigned sequence, thus changing the length of the |
| 213 | target sequence, if the object allows it. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 214 | |
| 215 | (In the current implementation, the syntax for targets is taken to be the same |
| 216 | as for expressions, and invalid syntax is rejected during the code generation |
| 217 | phase, causing less detailed error messages.) |
| 218 | |
| 219 | WARNING: Although the definition of assignment implies that overlaps between the |
| 220 | left-hand side and the right-hand side are 'safe' (for example ``a, b = b, a`` |
| 221 | swaps two variables), overlaps *within* the collection of assigned-to variables |
| 222 | are not safe! For instance, the following program prints ``[0, 2]``:: |
| 223 | |
| 224 | x = [0, 1] |
| 225 | i = 0 |
| 226 | i, x[i] = 1, 2 |
Georg Brandl | 6911e3c | 2007-09-04 07:15:32 +0000 | [diff] [blame] | 227 | print(x) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 228 | |
| 229 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 230 | .. seealso:: |
| 231 | |
| 232 | :pep:`3132` - Extended Iterable Unpacking |
| 233 | The specification for the ``*target`` feature. |
| 234 | |
| 235 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 236 | .. _augassign: |
| 237 | |
| 238 | Augmented assignment statements |
| 239 | ------------------------------- |
| 240 | |
| 241 | .. index:: |
| 242 | pair: augmented; assignment |
| 243 | single: statement; assignment, augmented |
| 244 | |
| 245 | Augmented assignment is the combination, in a single statement, of a binary |
| 246 | operation and an assignment statement: |
| 247 | |
| 248 | .. productionlist:: |
| 249 | augmented_assignment_stmt: `target` `augop` (`expression_list` | `yield_expression`) |
| 250 | augop: "+=" | "-=" | "*=" | "/=" | "%=" | "**=" |
| 251 | : | ">>=" | "<<=" | "&=" | "^=" | "|=" |
| 252 | |
| 253 | (See section :ref:`primaries` for the syntax definitions for the last three |
| 254 | symbols.) |
| 255 | |
| 256 | An augmented assignment evaluates the target (which, unlike normal assignment |
| 257 | statements, cannot be an unpacking) and the expression list, performs the binary |
| 258 | operation specific to the type of assignment on the two operands, and assigns |
| 259 | the result to the original target. The target is only evaluated once. |
| 260 | |
| 261 | An augmented assignment expression like ``x += 1`` can be rewritten as ``x = x + |
| 262 | 1`` to achieve a similar, but not exactly equal effect. In the augmented |
| 263 | version, ``x`` is only evaluated once. Also, when possible, the actual operation |
| 264 | is performed *in-place*, meaning that rather than creating a new object and |
| 265 | assigning that to the target, the old object is modified instead. |
| 266 | |
| 267 | With the exception of assigning to tuples and multiple targets in a single |
| 268 | statement, the assignment done by augmented assignment statements is handled the |
| 269 | same way as normal assignments. Similarly, with the exception of the possible |
| 270 | *in-place* behavior, the binary operation performed by augmented assignment is |
| 271 | the same as the normal binary operations. |
| 272 | |
| 273 | For targets which are attribute references, the initial value is retrieved with |
| 274 | a :meth:`getattr` and the result is assigned with a :meth:`setattr`. Notice |
| 275 | that the two methods do not necessarily refer to the same variable. When |
| 276 | :meth:`getattr` refers to a class variable, :meth:`setattr` still writes to an |
| 277 | instance variable. For example:: |
| 278 | |
| 279 | class A: |
| 280 | x = 3 # class variable |
| 281 | a = A() |
| 282 | a.x += 1 # writes a.x as 4 leaving A.x as 3 |
| 283 | |
| 284 | |
Thomas Wouters | 1b7f891 | 2007-09-19 03:06:30 +0000 | [diff] [blame] | 285 | .. _assert: |
| 286 | |
| 287 | The :keyword:`assert` statement |
| 288 | =============================== |
| 289 | |
| 290 | .. index:: |
| 291 | statement: assert |
| 292 | pair: debugging; assertions |
| 293 | |
| 294 | Assert statements are a convenient way to insert debugging assertions into a |
| 295 | program: |
| 296 | |
| 297 | .. productionlist:: |
| 298 | assert_stmt: "assert" `expression` ["," `expression`] |
| 299 | |
| 300 | The simple form, ``assert expression``, is equivalent to :: |
| 301 | |
| 302 | if __debug__: |
| 303 | if not expression: raise AssertionError |
| 304 | |
| 305 | The extended form, ``assert expression1, expression2``, is equivalent to :: |
| 306 | |
| 307 | if __debug__: |
Georg Brandl | 18a499d | 2007-12-29 10:57:11 +0000 | [diff] [blame] | 308 | if not expression1: raise AssertionError(expression2) |
Thomas Wouters | 1b7f891 | 2007-09-19 03:06:30 +0000 | [diff] [blame] | 309 | |
| 310 | .. index:: |
| 311 | single: __debug__ |
| 312 | exception: AssertionError |
| 313 | |
Christian Heimes | 5b5e81c | 2007-12-31 16:14:33 +0000 | [diff] [blame] | 314 | These equivalences assume that :const:`__debug__` and :exc:`AssertionError` refer to |
Thomas Wouters | 1b7f891 | 2007-09-19 03:06:30 +0000 | [diff] [blame] | 315 | the built-in variables with those names. In the current implementation, the |
Christian Heimes | 5b5e81c | 2007-12-31 16:14:33 +0000 | [diff] [blame] | 316 | built-in variable :const:`__debug__` is ``True`` under normal circumstances, |
Thomas Wouters | 1b7f891 | 2007-09-19 03:06:30 +0000 | [diff] [blame] | 317 | ``False`` when optimization is requested (command line option -O). The current |
| 318 | code generator emits no code for an assert statement when optimization is |
| 319 | requested at compile time. Note that it is unnecessary to include the source |
| 320 | code for the expression that failed in the error message; it will be displayed |
| 321 | as part of the stack trace. |
| 322 | |
Christian Heimes | 5b5e81c | 2007-12-31 16:14:33 +0000 | [diff] [blame] | 323 | Assignments to :const:`__debug__` are illegal. The value for the built-in variable |
Thomas Wouters | 1b7f891 | 2007-09-19 03:06:30 +0000 | [diff] [blame] | 324 | is determined when the interpreter starts. |
| 325 | |
| 326 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 327 | .. _pass: |
| 328 | |
| 329 | The :keyword:`pass` statement |
| 330 | ============================= |
| 331 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 332 | .. index:: |
| 333 | statement: pass |
| 334 | pair: null; operation |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 335 | pair: null; operation |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 336 | |
| 337 | .. productionlist:: |
| 338 | pass_stmt: "pass" |
| 339 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 340 | :keyword:`pass` is a null operation --- when it is executed, nothing happens. |
| 341 | It is useful as a placeholder when a statement is required syntactically, but no |
| 342 | code needs to be executed, for example:: |
| 343 | |
| 344 | def f(arg): pass # a function that does nothing (yet) |
| 345 | |
| 346 | class C: pass # a class with no methods (yet) |
| 347 | |
| 348 | |
| 349 | .. _del: |
| 350 | |
| 351 | The :keyword:`del` statement |
| 352 | ============================ |
| 353 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 354 | .. index:: |
| 355 | statement: del |
| 356 | pair: deletion; target |
| 357 | triple: deletion; target; list |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 358 | |
| 359 | .. productionlist:: |
| 360 | del_stmt: "del" `target_list` |
| 361 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 362 | Deletion is recursively defined very similar to the way assignment is defined. |
| 363 | Rather that spelling it out in full details, here are some hints. |
| 364 | |
| 365 | Deletion of a target list recursively deletes each target, from left to right. |
| 366 | |
| 367 | .. index:: |
| 368 | statement: global |
| 369 | pair: unbinding; name |
| 370 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 371 | Deletion of a name removes the binding of that name from the local or global |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 372 | namespace, depending on whether the name occurs in a :keyword:`global` statement |
| 373 | in the same code block. If the name is unbound, a :exc:`NameError` exception |
| 374 | will be raised. |
| 375 | |
| 376 | .. index:: pair: free; variable |
| 377 | |
| 378 | It is illegal to delete a name from the local namespace if it occurs as a free |
| 379 | variable in a nested block. |
| 380 | |
| 381 | .. index:: pair: attribute; deletion |
| 382 | |
| 383 | Deletion of attribute references, subscriptions and slicings is passed to the |
| 384 | primary object involved; deletion of a slicing is in general equivalent to |
| 385 | assignment of an empty slice of the right type (but even this is determined by |
| 386 | the sliced object). |
| 387 | |
| 388 | |
| 389 | .. _return: |
| 390 | |
| 391 | The :keyword:`return` statement |
| 392 | =============================== |
| 393 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 394 | .. index:: |
| 395 | statement: return |
| 396 | pair: function; definition |
| 397 | pair: class; definition |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 398 | |
| 399 | .. productionlist:: |
| 400 | return_stmt: "return" [`expression_list`] |
| 401 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 402 | :keyword:`return` may only occur syntactically nested in a function definition, |
| 403 | not within a nested class definition. |
| 404 | |
| 405 | If an expression list is present, it is evaluated, else ``None`` is substituted. |
| 406 | |
| 407 | :keyword:`return` leaves the current function call with the expression list (or |
| 408 | ``None``) as return value. |
| 409 | |
| 410 | .. index:: keyword: finally |
| 411 | |
| 412 | When :keyword:`return` passes control out of a :keyword:`try` statement with a |
| 413 | :keyword:`finally` clause, that :keyword:`finally` clause is executed before |
| 414 | really leaving the function. |
| 415 | |
| 416 | In a generator function, the :keyword:`return` statement is not allowed to |
| 417 | include an :token:`expression_list`. In that context, a bare :keyword:`return` |
| 418 | indicates that the generator is done and will cause :exc:`StopIteration` to be |
| 419 | raised. |
| 420 | |
| 421 | |
| 422 | .. _yield: |
| 423 | |
| 424 | The :keyword:`yield` statement |
| 425 | ============================== |
| 426 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 427 | .. index:: |
| 428 | statement: yield |
| 429 | single: generator; function |
| 430 | single: generator; iterator |
| 431 | single: function; generator |
| 432 | exception: StopIteration |
| 433 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 434 | .. productionlist:: |
| 435 | yield_stmt: `yield_expression` |
| 436 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 437 | The :keyword:`yield` statement is only used when defining a generator function, |
| 438 | and is only used in the body of the generator function. Using a :keyword:`yield` |
| 439 | statement in a function definition is sufficient to cause that definition to |
| 440 | create a generator function instead of a normal function. |
Christian Heimes | 33fe809 | 2008-04-13 13:53:33 +0000 | [diff] [blame] | 441 | When a generator function is called, it returns an iterator known as a generator |
| 442 | iterator, or more commonly, a generator. The body of the generator function is |
| 443 | executed by calling the generator's :meth:`next` method repeatedly until it |
| 444 | raises an exception. |
| 445 | |
| 446 | When a :keyword:`yield` statement is executed, the state of the generator is |
| 447 | frozen and the value of :token:`expression_list` is returned to :meth:`next`'s |
| 448 | caller. By "frozen" we mean that all local state is retained, including the |
| 449 | current bindings of local variables, the instruction pointer, and the internal |
| 450 | evaluation stack: enough information is saved so that the next time :meth:`next` |
| 451 | is invoked, the function can proceed exactly as if the :keyword:`yield` |
| 452 | statement were just another external call. |
| 453 | |
Georg Brandl | e6bcc91 | 2008-05-12 18:05:20 +0000 | [diff] [blame^] | 454 | The :keyword:`yield` statement is allowed in the :keyword:`try` clause of a |
| 455 | :keyword:`try` ... :keyword:`finally` construct. If the generator is not |
| 456 | resumed before it is finalized (by reaching a zero reference count or by being |
| 457 | garbage collected), the generator-iterator's :meth:`close` method will be |
| 458 | called, allowing any pending :keyword:`finally` clauses to execute. |
Christian Heimes | 33fe809 | 2008-04-13 13:53:33 +0000 | [diff] [blame] | 459 | |
| 460 | .. seealso:: |
| 461 | |
| 462 | :pep:`0255` - Simple Generators |
| 463 | The proposal for adding generators and the :keyword:`yield` statement to Python. |
| 464 | |
| 465 | :pep:`0342` - Coroutines via Enhanced Generators |
| 466 | The proposal that, among other generator enhancements, proposed allowing |
| 467 | :keyword:`yield` to appear inside a :keyword:`try` ... :keyword:`finally` block. |
| 468 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 469 | |
| 470 | .. _raise: |
| 471 | |
| 472 | The :keyword:`raise` statement |
| 473 | ============================== |
| 474 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 475 | .. index:: |
| 476 | statement: raise |
| 477 | single: exception |
| 478 | pair: raising; exception |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 479 | |
| 480 | .. productionlist:: |
Georg Brandl | e06de8b | 2008-05-05 21:42:51 +0000 | [diff] [blame] | 481 | raise_stmt: "raise" [`expression` ["from" `expression`]] |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 482 | |
| 483 | If no expressions are present, :keyword:`raise` re-raises the last exception |
| 484 | that was active in the current scope. If no exception is active in the current |
| 485 | scope, a :exc:`TypeError` exception is raised indicating that this is an error |
Alexandre Vassalotti | f260e44 | 2008-05-11 19:59:59 +0000 | [diff] [blame] | 486 | (if running under IDLE, a :exc:`queue.Empty` exception is raised instead). |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 487 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 488 | Otherwise, :keyword:`raise` evaluates the first expression as the exception |
| 489 | object. It must be either a subclass or an instance of :class:`BaseException`. |
| 490 | If it is a class, the exception instance will be obtained when needed by |
| 491 | instantiating the class with no arguments. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 492 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 493 | The :dfn:`type` of the exception is the exception instance's class, the |
| 494 | :dfn:`value` is the instance itself. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 495 | |
| 496 | .. index:: object: traceback |
| 497 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 498 | A traceback object is normally created automatically when an exception is raised |
Georg Brandl | e06de8b | 2008-05-05 21:42:51 +0000 | [diff] [blame] | 499 | and attached to it as the :attr:`__traceback__` attribute, which is writable. |
| 500 | You can create an exception and set your own traceback in one step using the |
| 501 | :meth:`with_traceback` exception method (which returns the same exception |
| 502 | instance, with its traceback set to its argument), like so:: |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 503 | |
| 504 | raise RuntimeError("foo occurred").with_traceback(tracebackobj) |
| 505 | |
Georg Brandl | e06de8b | 2008-05-05 21:42:51 +0000 | [diff] [blame] | 506 | .. XXX document exception chaining |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 507 | |
| 508 | The "from" clause is used for exception chaining, which is not documented yet. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 509 | |
| 510 | Additional information on exceptions can be found in section :ref:`exceptions`, |
| 511 | and information about handling exceptions is in section :ref:`try`. |
| 512 | |
| 513 | |
| 514 | .. _break: |
| 515 | |
| 516 | The :keyword:`break` statement |
| 517 | ============================== |
| 518 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 519 | .. index:: |
| 520 | statement: break |
| 521 | statement: for |
| 522 | statement: while |
| 523 | pair: loop; statement |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 524 | |
| 525 | .. productionlist:: |
| 526 | break_stmt: "break" |
| 527 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 528 | :keyword:`break` may only occur syntactically nested in a :keyword:`for` or |
| 529 | :keyword:`while` loop, but not nested in a function or class definition within |
| 530 | that loop. |
| 531 | |
| 532 | .. index:: keyword: else |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 533 | pair: loop control; target |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 534 | |
| 535 | It terminates the nearest enclosing loop, skipping the optional :keyword:`else` |
| 536 | clause if the loop has one. |
| 537 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 538 | If a :keyword:`for` loop is terminated by :keyword:`break`, the loop control |
| 539 | target keeps its current value. |
| 540 | |
| 541 | .. index:: keyword: finally |
| 542 | |
| 543 | When :keyword:`break` passes control out of a :keyword:`try` statement with a |
| 544 | :keyword:`finally` clause, that :keyword:`finally` clause is executed before |
| 545 | really leaving the loop. |
| 546 | |
| 547 | |
| 548 | .. _continue: |
| 549 | |
| 550 | The :keyword:`continue` statement |
| 551 | ================================= |
| 552 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 553 | .. index:: |
| 554 | statement: continue |
| 555 | statement: for |
| 556 | statement: while |
| 557 | pair: loop; statement |
| 558 | keyword: finally |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 559 | |
| 560 | .. productionlist:: |
| 561 | continue_stmt: "continue" |
| 562 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 563 | :keyword:`continue` may only occur syntactically nested in a :keyword:`for` or |
| 564 | :keyword:`while` loop, but not nested in a function or class definition or |
Christian Heimes | dd15f6c | 2008-03-16 00:07:10 +0000 | [diff] [blame] | 565 | :keyword:`finally` clause within that loop. It continues with the next |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 566 | cycle of the nearest enclosing loop. |
| 567 | |
Christian Heimes | dd15f6c | 2008-03-16 00:07:10 +0000 | [diff] [blame] | 568 | When :keyword:`continue` passes control out of a :keyword:`try` statement with a |
| 569 | :keyword:`finally` clause, that :keyword:`finally` clause is executed before |
| 570 | really starting the next loop cycle. |
| 571 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 572 | |
| 573 | .. _import: |
Christian Heimes | 5b5e81c | 2007-12-31 16:14:33 +0000 | [diff] [blame] | 574 | .. _from: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 575 | |
| 576 | The :keyword:`import` statement |
| 577 | =============================== |
| 578 | |
| 579 | .. index:: |
| 580 | statement: import |
| 581 | single: module; importing |
| 582 | pair: name; binding |
| 583 | keyword: from |
| 584 | |
| 585 | .. productionlist:: |
| 586 | import_stmt: "import" `module` ["as" `name`] ( "," `module` ["as" `name`] )* |
| 587 | : | "from" `relative_module` "import" `identifier` ["as" `name`] |
| 588 | : ( "," `identifier` ["as" `name`] )* |
| 589 | : | "from" `relative_module` "import" "(" `identifier` ["as" `name`] |
| 590 | : ( "," `identifier` ["as" `name`] )* [","] ")" |
| 591 | : | "from" `module` "import" "*" |
| 592 | module: (`identifier` ".")* `identifier` |
| 593 | relative_module: "."* `module` | "."+ |
| 594 | name: `identifier` |
| 595 | |
| 596 | Import statements are executed in two steps: (1) find a module, and initialize |
| 597 | it if necessary; (2) define a name or names in the local namespace (of the scope |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 598 | where the :keyword:`import` statement occurs). The first form (without |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 599 | :keyword:`from`) repeats these steps for each identifier in the list. The form |
| 600 | with :keyword:`from` performs step (1) once, and then performs step (2) |
| 601 | repeatedly. |
| 602 | |
| 603 | In this context, to "initialize" a built-in or extension module means to call an |
| 604 | initialization function that the module must provide for the purpose (in the |
| 605 | reference implementation, the function's name is obtained by prepending string |
| 606 | "init" to the module's name); to "initialize" a Python-coded module means to |
| 607 | execute the module's body. |
| 608 | |
| 609 | .. index:: |
| 610 | single: modules (in module sys) |
| 611 | single: sys.modules |
| 612 | pair: module; name |
| 613 | pair: built-in; module |
| 614 | pair: user-defined; module |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 615 | pair: filename; extension |
| 616 | triple: module; search; path |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 617 | module: sys |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 618 | |
| 619 | The system maintains a table of modules that have been or are being initialized, |
| 620 | indexed by module name. This table is accessible as ``sys.modules``. When a |
| 621 | module name is found in this table, step (1) is finished. If not, a search for |
| 622 | a module definition is started. When a module is found, it is loaded. Details |
| 623 | of the module searching and loading process are implementation and platform |
| 624 | specific. It generally involves searching for a "built-in" module with the |
| 625 | given name and then searching a list of locations given as ``sys.path``. |
| 626 | |
| 627 | .. index:: |
| 628 | pair: module; initialization |
| 629 | exception: ImportError |
| 630 | single: code block |
| 631 | exception: SyntaxError |
| 632 | |
| 633 | If a built-in module is found, its built-in initialization code is executed and |
| 634 | step (1) is finished. If no matching file is found, :exc:`ImportError` is |
| 635 | raised. If a file is found, it is parsed, yielding an executable code block. If |
| 636 | a syntax error occurs, :exc:`SyntaxError` is raised. Otherwise, an empty module |
| 637 | of the given name is created and inserted in the module table, and then the code |
| 638 | block is executed in the context of this module. Exceptions during this |
| 639 | execution terminate step (1). |
| 640 | |
| 641 | When step (1) finishes without raising an exception, step (2) can begin. |
| 642 | |
| 643 | The first form of :keyword:`import` statement binds the module name in the local |
| 644 | namespace to the module object, and then goes on to import the next identifier, |
| 645 | if any. If the module name is followed by :keyword:`as`, the name following |
| 646 | :keyword:`as` is used as the local name for the module. |
| 647 | |
| 648 | .. index:: |
| 649 | pair: name; binding |
| 650 | exception: ImportError |
| 651 | |
| 652 | The :keyword:`from` form does not bind the module name: it goes through the list |
| 653 | of identifiers, looks each one of them up in the module found in step (1), and |
| 654 | binds the name in the local namespace to the object thus found. As with the |
| 655 | first form of :keyword:`import`, an alternate local name can be supplied by |
| 656 | specifying ":keyword:`as` localname". If a name is not found, |
| 657 | :exc:`ImportError` is raised. If the list of identifiers is replaced by a star |
| 658 | (``'*'``), all public names defined in the module are bound in the local |
| 659 | namespace of the :keyword:`import` statement.. |
| 660 | |
| 661 | .. index:: single: __all__ (optional module attribute) |
| 662 | |
| 663 | The *public names* defined by a module are determined by checking the module's |
| 664 | namespace for a variable named ``__all__``; if defined, it must be a sequence of |
| 665 | strings which are names defined or imported by that module. The names given in |
| 666 | ``__all__`` are all considered public and are required to exist. If ``__all__`` |
| 667 | is not defined, the set of public names includes all names found in the module's |
| 668 | namespace which do not begin with an underscore character (``'_'``). |
| 669 | ``__all__`` should contain the entire public API. It is intended to avoid |
| 670 | accidentally exporting items that are not part of the API (such as library |
| 671 | modules which were imported and used within the module). |
| 672 | |
| 673 | The :keyword:`from` form with ``*`` may only occur in a module scope. If the |
| 674 | wild card form of import --- ``import *`` --- is used in a function and the |
| 675 | function contains or is a nested block with free variables, the compiler will |
| 676 | raise a :exc:`SyntaxError`. |
| 677 | |
| 678 | .. index:: |
| 679 | keyword: from |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 680 | statement: from |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 681 | triple: hierarchical; module; names |
| 682 | single: packages |
| 683 | single: __init__.py |
| 684 | |
| 685 | **Hierarchical module names:** when the module names contains one or more dots, |
| 686 | the module search path is carried out differently. The sequence of identifiers |
| 687 | up to the last dot is used to find a "package"; the final identifier is then |
| 688 | searched inside the package. A package is generally a subdirectory of a |
| 689 | directory on ``sys.path`` that has a file :file:`__init__.py`. [XXX Can't be |
| 690 | bothered to spell this out right now; see the URL |
| 691 | http://www.python.org/doc/essays/packages.html for more details, also about how |
| 692 | the module search works from inside a package.] |
| 693 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 694 | .. index:: builtin: __import__ |
| 695 | |
| 696 | The built-in function :func:`__import__` is provided to support applications |
| 697 | that determine which modules need to be loaded dynamically; refer to |
| 698 | :ref:`built-in-funcs` for additional information. |
| 699 | |
| 700 | |
| 701 | .. _future: |
| 702 | |
| 703 | Future statements |
| 704 | ----------------- |
| 705 | |
| 706 | .. index:: pair: future; statement |
| 707 | |
| 708 | A :dfn:`future statement` is a directive to the compiler that a particular |
| 709 | module should be compiled using syntax or semantics that will be available in a |
| 710 | specified future release of Python. The future statement is intended to ease |
| 711 | migration to future versions of Python that introduce incompatible changes to |
| 712 | the language. It allows use of the new features on a per-module basis before |
| 713 | the release in which the feature becomes standard. |
| 714 | |
| 715 | .. productionlist:: * |
| 716 | future_statement: "from" "__future__" "import" feature ["as" name] |
| 717 | : ("," feature ["as" name])* |
| 718 | : | "from" "__future__" "import" "(" feature ["as" name] |
| 719 | : ("," feature ["as" name])* [","] ")" |
| 720 | feature: identifier |
| 721 | name: identifier |
| 722 | |
| 723 | A future statement must appear near the top of the module. The only lines that |
| 724 | can appear before a future statement are: |
| 725 | |
| 726 | * the module docstring (if any), |
| 727 | * comments, |
| 728 | * blank lines, and |
| 729 | * other future statements. |
| 730 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 731 | .. XXX change this if future is cleaned out |
| 732 | |
| 733 | The features recognized by Python 3.0 are ``absolute_import``, ``division``, |
| 734 | ``generators``, ``nested_scopes`` and ``with_statement``. They are all |
| 735 | redundant because they are always enabled, and only kept for backwards |
| 736 | compatibility. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 737 | |
| 738 | A future statement is recognized and treated specially at compile time: Changes |
| 739 | to the semantics of core constructs are often implemented by generating |
| 740 | different code. It may even be the case that a new feature introduces new |
| 741 | incompatible syntax (such as a new reserved word), in which case the compiler |
| 742 | may need to parse the module differently. Such decisions cannot be pushed off |
| 743 | until runtime. |
| 744 | |
| 745 | For any given release, the compiler knows which feature names have been defined, |
| 746 | and raises a compile-time error if a future statement contains a feature not |
| 747 | known to it. |
| 748 | |
| 749 | The direct runtime semantics are the same as for any import statement: there is |
| 750 | a standard module :mod:`__future__`, described later, and it will be imported in |
| 751 | the usual way at the time the future statement is executed. |
| 752 | |
| 753 | The interesting runtime semantics depend on the specific feature enabled by the |
| 754 | future statement. |
| 755 | |
| 756 | Note that there is nothing special about the statement:: |
| 757 | |
| 758 | import __future__ [as name] |
| 759 | |
| 760 | That is not a future statement; it's an ordinary import statement with no |
| 761 | special semantics or syntax restrictions. |
| 762 | |
| 763 | Code compiled by calls to the builtin functions :func:`exec` and :func:`compile` |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 764 | that occur in a module :mod:`M` containing a future statement will, by default, |
| 765 | use the new syntax or semantics associated with the future statement. This can |
| 766 | be controlled by optional arguments to :func:`compile` --- see the documentation |
| 767 | of that function for details. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 768 | |
| 769 | A future statement typed at an interactive interpreter prompt will take effect |
| 770 | for the rest of the interpreter session. If an interpreter is started with the |
| 771 | :option:`-i` option, is passed a script name to execute, and the script includes |
| 772 | a future statement, it will be in effect in the interactive session started |
| 773 | after the script is executed. |
| 774 | |
| 775 | |
| 776 | .. _global: |
| 777 | |
| 778 | The :keyword:`global` statement |
| 779 | =============================== |
| 780 | |
Christian Heimes | faf2f63 | 2008-01-06 16:59:19 +0000 | [diff] [blame] | 781 | .. index:: |
| 782 | statement: global |
| 783 | triple: global; name; binding |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 784 | |
| 785 | .. productionlist:: |
| 786 | global_stmt: "global" `identifier` ("," `identifier`)* |
| 787 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 788 | The :keyword:`global` statement is a declaration which holds for the entire |
| 789 | current code block. It means that the listed identifiers are to be interpreted |
| 790 | as globals. It would be impossible to assign to a global variable without |
| 791 | :keyword:`global`, although free variables may refer to globals without being |
| 792 | declared global. |
| 793 | |
| 794 | Names listed in a :keyword:`global` statement must not be used in the same code |
| 795 | block textually preceding that :keyword:`global` statement. |
| 796 | |
| 797 | Names listed in a :keyword:`global` statement must not be defined as formal |
| 798 | parameters or in a :keyword:`for` loop control target, :keyword:`class` |
| 799 | definition, function definition, or :keyword:`import` statement. |
| 800 | |
| 801 | (The current implementation does not enforce the latter two restrictions, but |
| 802 | programs should not abuse this freedom, as future implementations may enforce |
| 803 | them or silently change the meaning of the program.) |
| 804 | |
| 805 | .. index:: |
| 806 | builtin: exec |
| 807 | builtin: eval |
| 808 | builtin: compile |
| 809 | |
| 810 | **Programmer's note:** the :keyword:`global` is a directive to the parser. It |
| 811 | applies only to code parsed at the same time as the :keyword:`global` statement. |
| 812 | In particular, a :keyword:`global` statement contained in a string or code |
| 813 | object supplied to the builtin :func:`exec` function does not affect the code |
| 814 | block *containing* the function call, and code contained in such a string is |
| 815 | unaffected by :keyword:`global` statements in the code containing the function |
| 816 | call. The same applies to the :func:`eval` and :func:`compile` functions. |
| 817 | |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 818 | |
| 819 | .. _nonlocal: |
| 820 | |
| 821 | The :keyword:`nonlocal` statement |
| 822 | ================================= |
| 823 | |
| 824 | .. index:: statement: nonlocal |
| 825 | |
| 826 | .. productionlist:: |
| 827 | nonlocal_stmt: "nonlocal" `identifier` ("," `identifier`)* |
| 828 | |
Georg Brandl | c5d98b4 | 2007-12-04 18:11:03 +0000 | [diff] [blame] | 829 | .. XXX add when implemented |
| 830 | : ["=" (`target_list` "=")+ `expression_list`] |
| 831 | : | "nonlocal" `identifier` `augop` `expression_list` |
| 832 | |
| 833 | The :keyword:`nonlocal` statement causes the listed identifiers to refer to |
| 834 | previously bound variables in the nearest enclosing scope. This is important |
| 835 | because the default behavior for binding is to search the local namespace |
| 836 | first. The statement allows encapsulated code to rebind variables outside of |
| 837 | the local scope besides the global (module) scope. |
| 838 | |
Georg Brandl | c5d98b4 | 2007-12-04 18:11:03 +0000 | [diff] [blame] | 839 | .. XXX not implemented |
| 840 | The :keyword:`nonlocal` statement may prepend an assignment or augmented |
| 841 | assignment, but not an expression. |
| 842 | |
| 843 | Names listed in a :keyword:`nonlocal` statement, unlike to those listed in a |
| 844 | :keyword:`global` statement, must refer to pre-existing bindings in an |
| 845 | enclosing scope (the scope in which a new binding should be created cannot |
| 846 | be determined unambiguously). |
| 847 | |
| 848 | Names listed in a :keyword:`nonlocal` statement must not collide with |
| 849 | pre-existing bindings in the local scope. |
| 850 | |
| 851 | .. seealso:: |
| 852 | |
| 853 | :pep:`3104` - Access to Names in Outer Scopes |
| 854 | The specification for the :keyword:`nonlocal` statement. |
Georg Brandl | 02c3056 | 2007-09-07 17:52:53 +0000 | [diff] [blame] | 855 | |
| 856 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 857 | .. rubric:: Footnotes |
| 858 | |
| 859 | .. [#] It may occur within an :keyword:`except` or :keyword:`else` clause. The |
Georg Brandl | c5d98b4 | 2007-12-04 18:11:03 +0000 | [diff] [blame] | 860 | restriction on occurring in the :keyword:`try` clause is implementor's |
| 861 | laziness and will eventually be lifted. |