Doesnt this all boil down to being able to monitor PyDict for changes to it's key-space?
The keys are immutable anyway so the instances of PyDict could manage a opaque value (in fact, a counter) that changes every time a new value is written to any key. Once we get a reference out of the dict, we can can do very fast lookups by passing the key, the reference we know from the last lookup and our last state. The lookup returns a new reference and the new state. If the dict has not changed, the state doesnt change and the reference is simply taken from the passed value passed to the lookup. That way the code remains the same no matter if the dict has changed or not. 2011/1/4 Michael Foord <fuzzy...@voidspace.org.uk>: > On 04/01/2011 16:54, Barry Warsaw wrote: > > On Jan 04, 2011, at 10:21 AM, Alex Gaynor wrote: > > Ugh, I can't be the only one who finds these special cases to be a little > nasty? > > Special cases aren't special enough to break the rules. > > Yeah, I agree. Still it would be interesting to see what kind of > performance > improvement this would result in. That seems to be the only way to decide > whether the cost is worth the benefit. > > Outside of testing, I do agree that most of the builtins could be pretty > safely optimized (even open()). There needs to be a way to stop all > optimizations for testing purposes. Perhaps a sys variable, plus command > line > option and/or environment variable? > > Although testing in an environment deliberately different from production is > a recipe for hard to diagnose bugs. > > Michael > > -Barry > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > > -- > http://www.voidspace.org.uk/ > > May you do good and not evil > May you find forgiveness for yourself and forgive others > May you share freely, never taking more than you give. > -- the sqlite blessing http://www.sqlite.org/different.html > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lukas.lueg%40gmail.com > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
