Showing content from http://mail.python.org/pipermail/python-dev/attachments/20131107/85ef2016/attachment.html below:
<p dir="ltr"><br>
On 7 Nov 2013 03:18, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> Le 06/11/2013 06:41, Nick Coghlan a écrit :<br>
><br>
>><br>
>> The behaviour of mutating builtin containers while iterating over them<br>
>> is formally undefined beyond "it won't segfault" (one of the few such<br>
>> undefined behaviours in Python). The associated exceptions are thus<br>
>> strictly "best effort given other constraints".<br>
><br>
><br>
> Not sure what you mean with "formally undefined". For example, you can perfectly well change a list's contents while iterating over it, and I bet there's a lot of code that relies on that, as in::<br>
><br>
> for i, value in enumerate(mylist):<br>
> if some_condition(value):<br>
> mylist[i] = some_function(value)<br>
><br>
> If you change "builtin containers" to "builtin unordered containers", then you probably are closer to the truth :)</p>
<p dir="ltr">I meant changing the length rather than just the contents of an existing entry. Even lists get a little odd if you add and remove entries while iterating (although I agree the sequence case is much better defined than the unordered container case).</p>
<p dir="ltr">Cheers,<br>
Nick.<br>
</p>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4