On 7 Nov 2013 03:18, "Antoine Pitrou" wrote:
>
> Le 06/11/2013 06:41, Nick Coghlan a écrit :
>
>>
>> The behaviour of mutating builtin containers while iterating over them
>> is formally undefined beyond "it won't segfault" (one of the few such
>> undefined behaviours in Python). The associated ex
Thank you, Raymond, and everyone else who responded both here and on the
tracker.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
06.11.13 21:12, Eric Snow написав(ла):
Just to clarify, do you mean we should only guard against
modifications to the dict's keys during its iterator's __next__()?
Changes to the values during __next__() would be okay, as would
changes to the keys if they happen outside __next__()?
Dict iterati
On Wed, Nov 6, 2013 at 11:02 AM, Serhiy Storchaka wrote:
> Actually we should guard not against changing dict during iteration, but
> against iterating modifying dict (and only such modifications which change
> dict's keys).
s/iterating modifying/iteration modifying/ ?
Just to clarify, do you me
06.11.13 07:41, Nick Coghlan написав(ла):
If the benchmark suite indicates there's no measurable speed penalty
then such a patch may be worth reconsidering.
I don't see any significant speed difference even in artificial
presumably worst case (a lot of items assignment in tight loop).
If you
Le 06/11/2013 06:41, Nick Coghlan a écrit :
The behaviour of mutating builtin containers while iterating over them
is formally undefined beyond "it won't segfault" (one of the few such
undefined behaviours in Python). The associated exceptions are thus
strictly "best effort given other constrain
On Wed, 06 Nov 2013 16:10:16 +0100, Victor Stinner
wrote:
> More recently, I added another exception if a dictionary is modified
> during a lookup.
>
> When I proposed a new frozendict type to secure my pysandbox project,
> Armin Rigo wrote that CPython segfaults must be fixed. So I fixed a
> co
2013/11/6 R. David Murray :
> On Wed, 06 Nov 2013 23:34:22 +1100, Steven D'Aprano
> wrote:
>> On Tue, Nov 05, 2013 at 08:38:09PM -0800, Ethan Furman wrote:
>>
>> > http://bugs.python.org/issue19332
>>
>> Duplicate of this: http://bugs.python.org/issue6017
>>
>> The conclusion on that also was tha
On Wed, 06 Nov 2013 23:34:22 +1100, Steven D'Aprano wrote:
> On Tue, Nov 05, 2013 at 08:38:09PM -0800, Ethan Furman wrote:
>
> > http://bugs.python.org/issue19332
>
> Duplicate of this: http://bugs.python.org/issue6017
>
> The conclusion on that also was that it is not worth guarding against
>
On Tue, Nov 05, 2013 at 08:38:09PM -0800, Ethan Furman wrote:
> http://bugs.python.org/issue19332
Duplicate of this: http://bugs.python.org/issue6017
The conclusion on that also was that it is not worth guarding against
such an unusual circumstance.
--
Steven
On Nov 5, 2013 10:42 PM, "Nick Coghlan" wrote:
> If the benchmark suite indicates there's no measurable speed penalty then
such a patch may be worth reconsidering. I'd be astonished if that was
actually the case, though - the lowest impact approach I can think of is to
check for live iterators whe
On 6 Nov 2013 15:02, "Ethan Furman" wrote:
>
> http://bugs.python.org/issue19332
>
> Summary:
>
> --> d = {1: 'one'}
> --> for k in d:
> ... d[k+1] = d[k] * k
> ...
> Traceback (most recent call last):
> File "", line 1, in
> RuntimeError: dictionary changed size during iteration
>
> --> for
http://bugs.python.org/issue19332
Summary:
--> d = {1: 'one'}
--> for k in d:
... d[k+1] = d[k] * k
...
Traceback (most recent call last):
File "", line 1, in
RuntimeError: dictionary changed size during iteration
--> for k in d:
... del d[k]
...
Traceback (most recent call last):
File
13 matches
Mail list logo
