I've been playing with dictionaries lately trying to stamp out a bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=112558&group_id=5470 It looks like any fix that really works risks a fair bit of performance, and that's not good. My best-effort fix so far is on SourceForge: http://sourceforge.net/patch/?func=detailpatch&patch_id=101277&group_id=5470 but doesn't quite work, according to Guido (I've not yet received instructions from him about how to reproduce the observed failure). None the less, performance is an issue for dictionaries, so I came up with the idea to use a specialized version for string keys. When I saw how few of the dictionaries created by the regression test ever had anything else, I tried to simply make all dictionaries the specialized variety (they can degrade themselves as needed). What I found was that just over 2% of the dictionaries created by running the regression test ever held any non-string keys; this may be very different for "real" programs, but I'm curious about how different. I've also done *no* performance testing on my patch for this yet, and don't expect it to be a big boost without something like the bug fix I mentioned above, but I could be wrong. If anyone would like to play with the idea, I've posted my current patch at: http://sourceforge.net/patch/?func=detailpatch&patch_id=101309&group_id=5470 Enjoy! ;) -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
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