Jeremy Hylton <jeremy@alum.mit.edu> writes:
> >>>>> "MH" == Michael Hudson <mwh21@cam.ac.uk> writes:
>
> MH> Jeremy Hylton <jeremy@alum.mit.edu> writes:
> >> >>>>> "MWH" == Michael Hudson <mwh21@cam.ac.uk> writes:
> >>
> MWH> [*] I thought that if you used the same keys when you were
> MWH> iterating over a dict you were safe. It seems not, at least as
> MWH> far as I could tell with mounds of debugging printf's.
> >>
> >> I did, too. Anyone know what the problems is?
>
> MH> The dict's resizing, it turns out.
>
> So a hack to make the iteration safe would be to assign and element
> and then delete it?
Yes. This would be gross beyond belief though. Particularly as the
normal case is for freevars to be empty.
> MH> I note that in PyDict_SetItem, the check to see if the dict
> MH> needs resizing occurs *before* it is known whether the key is
> MH> already in the dict. But if this is the problem, how come we
> MH> haven't been bitten by this before?
>
> It's probably unusual for a dictionary to be in this state when the
> compiler decides to update the values.
What I meant was that there are bits and pieces of code in the Python
core that blithely pass keys gotten from PyDict_Next into
PyDict_SetItem. From what I've just learnt, I'd expect this to
occasionally cause glitches of extreme confusing-ness. Though on
investigation, I don't think any of these bits of code are sensitive
to getting keys out multiple times (which is what happens in this case
- though you must be able to miss keys too). Might cause the odd leak
here and there.
Cheers,
M.
--
Clue: You've got the appropriate amount of hostility for the
Monastery, however you are metaphorically getting out of the
safari jeep and kicking the lions. -- coonec
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
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