[Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash

[noreply@sourceforge.net]

Patches item #409864, was updated on 2001-03-19 15:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Open
Priority: 7
Submitted By: Michael Hudson (mwh)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: lazy fix for Pings bizarre scoping crash

Initial Comment:
This is a minimal effort fix for Ping's report of a
crash on python-dev.

I don't know the new compile.c well enough to really
judge the best fix.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-22 07:49

Message:
Logged In: YES 
user_id=6380

Assigned to Fred for docs.  I believe the doc changes are in
the uploaded files.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-22 00:28

Message:
Logged In: YES 
user_id=6656

What about the doc changes and the test cases?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-03-21 16:06

Message:
Logged In: YES 
user_id=6380

This is closed now as far as I'm concerned.

The policy decision is that during a PyDict_Next() walk, you
may only call PyDict_SetItem() to replace the value for an
existing key.

Thanks Michael and Tim!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-21 11:29

Message:
Logged In: YES 
user_id=31435

After talking with Guido, I checked in a variant of next-
dict.diff; but didn't touch the rest of this.

dictobject.c rev 2.74.

PyDict_Next is now safe to use in loops that merely modify 
the values associated with existing dict keys via Py_SetItem
().  Other kinds of mutation are still blow-up-at-your-own-
risk.

Note to Jeremy:  it is NOT enough merely that the number of 
keys remain the same.  No existing key can be deleted, nor 
any new key inserted, during the loop.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-21 08:50

Message:
Logged In: YES 
user_id=31392

This is a policy question I'm not comfortable answering. 
Should we allow dict modification during a PyDict_Next()
iteration if the number of keys remains the same?

I can make the compiler work with or without this change.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-21 08:35

Message:
Logged In: YES 
user_id=6656

last one for now; this patch adds a test to
Modules/_testcapimodule.c to ensure that assigning to the
keys you're iterating over works as advertised in the patch
to the documentation.  i've checked that it finds this case
(i.e. the test fails before my patch and passes after).

the _testcapi tests aren't actually run anywhere, are they?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-21 08:11

Message:
Logged In: YES 
user_id=6656

add ping's test case to Lib/test/test_scope.py
(I'll stop this soon).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-21 08:07

Message:
Logged In: YES 
user_id=6656

and documents that you can assign to the keys as you iterate
over them.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-21 08:05

Message:
Logged In: YES 
user_id=6656

this alternative approach patches PyDict_Next to check for
resize.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-03-19 15:12

Message:
Logged In: YES 
user_id=6656

remember the file!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470