mirror of
https://github.com/satwikkansal/wtfpython
synced 2024-11-25 12:34:23 +01:00
Modifying a dictionary while iterating over it: Add note
Resolves https://github.com/satwikkansal/wtfpython/issues/53
This commit is contained in:
parent
dbbabbe564
commit
a0832c4459
4
README.md
vendored
4
README.md
vendored
@ -471,8 +471,8 @@ array_4 = [400, 500, 600]
|
|||||||
- In the first case, `array_1` is binded to the new object `[1,2,3,4,5]` and since the `in` clause is evaluated at the declaration time it still refers to the old object `[1,2,3,4]` (which is not destroyed).
|
- In the first case, `array_1` is binded to the new object `[1,2,3,4,5]` and since the `in` clause is evaluated at the declaration time it still refers to the old object `[1,2,3,4]` (which is not destroyed).
|
||||||
- In the second case, the slice assignment to `array_2` updates the same old object `[1,2,3,4]` to `[1,2,3,4,5]`. Hence both the `g2` and `array_2` still have reference to the same object (which has now been updated to `[1,2,3,4,5]`).
|
- In the second case, the slice assignment to `array_2` updates the same old object `[1,2,3,4]` to `[1,2,3,4,5]`. Hence both the `g2` and `array_2` still have reference to the same object (which has now been updated to `[1,2,3,4,5]`).
|
||||||
- Okay, going by the logic discussed so far, shouldn't be the value of `list(g)` in the third snippet be `[11, 21, 31, 12, 22, 32, 13, 23, 33]`? (because `array_3` and `array_4` are going to behave just like `array_1`). The reason why (only) `array_4` values got updated is explained in [PEP-289](https://www.python.org/dev/peps/pep-0289/#the-details)
|
- Okay, going by the logic discussed so far, shouldn't be the value of `list(g)` in the third snippet be `[11, 21, 31, 12, 22, 32, 13, 23, 33]`? (because `array_3` and `array_4` are going to behave just like `array_1`). The reason why (only) `array_4` values got updated is explained in [PEP-289](https://www.python.org/dev/peps/pep-0289/#the-details)
|
||||||
|
|
||||||
> Only the outermost for-expression is evaluated immediately, the other expressions are deferred until the generator is run.
|
> Only the outermost for-expression is evaluated immediately, the other expressions are deferred until the generator is run.
|
||||||
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@ -1425,7 +1425,7 @@ Yes, it runs for exactly **eight** times and stops.
|
|||||||
* Iteration over a dictionary that you edit at the same time is not supported.
|
* Iteration over a dictionary that you edit at the same time is not supported.
|
||||||
* It runs eight times because that's the point at which the dictionary resizes to hold more keys (we have eight deletion entries, so a resize is needed). This is actually an implementation detail.
|
* It runs eight times because that's the point at which the dictionary resizes to hold more keys (we have eight deletion entries, so a resize is needed). This is actually an implementation detail.
|
||||||
* How deleted keys are handled and when the resize occurs might be different for different Python implementations.
|
* How deleted keys are handled and when the resize occurs might be different for different Python implementations.
|
||||||
* For more information, you may refer to this StackOverflow [thread](https://stackoverflow.com/questions/44763802/bug-in-python-dict) explaining a similar example in detail.
|
* So for Python versions other than Python 2.7 - Python 3.5 the count might be different from 8 (but whatever the count is, it's going to be the same every time you run it). You can find some discussion around this [here](https://github.com/satwikkansal/wtfpython/issues/53) or in [this](https://stackoverflow.com/questions/44763802/bug-in-python-dict) StackOverflow thread.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user