Re: [Python-Dev] another dict crasher
"Tim Peters" <tim.one@home.com> writes:
[Michael Hudson]
Actually this crash was dict_print (I always forget about tp_print...).
We all should <wink>.
It's pretty easy to mend: [snip] I'm not sure this stops still more Machiavellian behaviour from crashing the interpreter,
Alas, it doesn't.
No, that's what my "dict[Machiavelli()] = Machiavelli()" example was demonstrating. If noone beats me to it, I'll post a better fix to sf next week, complete with test-cases and suitably "encouraging" comments. I can't easily see other examples of the problem; there certainly might be things you could do with comparisons that could trigger crashes, but that code's so hairy that it's almost impossible for me to be sure. There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare
and you can certainly get items being printed more than once or not at all. I'm not sure this last is a problem;
Those don't matter: in a long tradition, we buy "safety" not only at the cost of bloating the code, but also by making the true behavior in case of mutation unpredictable & inexplicable.
This is what I thought. [snip]
if the user's being this contrary there's only so much we can do to help him or her.
I'd prefer a similar internal immutable-dict trick that raised an exception if the user was pushing Python into a corner where "blow up or do something baffling" were its only choices. That would render the original example illegal, of course. But would that be a bad thing?
It's hard to see how.
What *should* it mean when the user invokes an operation on a container and mutates the container during that operation?
I don't think there's a meaning you can attach to this kind of behaviour. The "immutable dict trick" looks better the more I think about it, but I guess that will have to wait until Guido gets back from the sun... Cheers, M. -- incidentally, asking why things are "left out of the language" is a good sign that the asker is fairly clueless. -- Erik Naggum, comp.lang.lisp
[Michael Hudson]
... If noone beats me to it, I'll post a better fix to sf next week, complete with test-cases and suitably "encouraging" comments.
Ah, no need -- looks like I was doing that while you were writing this. Checked in already. So long as we're happy to settle for senseless results that simply don't blow up, the only other trick you really needed was to save away the value in a local vrbl and incref it across the key->string bit; then you don't have to worry about key->string deleting the value, or about the table entry it lived in going away (because you get the value from the (still-incref'ed) *local* vrbl later, not from the table again).
I can't easily see other examples of the problem; there certainly might be things you could do with comparisons that could trigger crashes, but that code's so hairy that it's almost impossible for me to be sure.
It's easy to be sure: any code that tries to remember anything about a dict (ditto any mutable object) across a "dangerous" call, other than the mere address of the object, is a place you *can* provoke a core dump. It may not be easy to provoke, and a given provoking test case may not fail across all platforms, or even every time you run it on a single platform, but it's "an obvious" hole all the same.
participants (2)
-
Michael Hudson -
Tim Peters