[Tim] >> It would be better in this case to go back to the top and start >> over. [Michael Hudson] > Yes. What you checked in is obviously better. I'll stick to being > the bearer of bad tidings... Hey, if it's fun, do whatever what you want! If you hadn't provoked me, I would have let it slide. Guido only cares about the end result <wink>. >> However, then an adversarial user can construct a case that never >> terminates. > I seem to have done this - it was odd, though - it only loops when I > bump the dict to fairly enormous preportions for reasons I don't > really (want to) understand. Pass it on. I deliberately "started over" via a recursive call instead of a goto so that an offending program would eventually die with a stack fault instead of just running forever. So if you're seeing something run forever, it may be a different problem. >> Unclear what to do. > Not worrying about it seems entirely reasonable I don't think anyone is happy leaving an exploitable hole in Python -- we endure enormous pain to plug those. Except, I guess, for buffer objects <wink>. I simply haven't thought of a good and efficient way to plug this one. Implementing an "internal immutable dict" type appeals to me, but it conflicts with that the affected routines believe to the core of their souls that exceptions raised during comparisons are to be ignored -- and raising a "hey, you can't change the dict *now*!" exception doesn't do the user any good if they never see it. Would plug the hole, but an *innocent* user would never know why their program failed to work as (probably) expected.
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