I mentioned it earlier, but I think you missed it: I was actually thinking inside the doctest itself. Your system of global assignment works as-is if you do it inside the doctests themselves (except for threads, but who runs doctests in multiple threads? gah!)
My only concern with that is muddying the documentation with long instructions on how to run the doctests. I'm not saying its not the best way though, because I do think the global assignments are a problem which would need to be resolved. Another way, though, would be to store compare functions by the module they were defined in and run assign them to the tests accordingly. This might end up quite complicated though. I think that a naive user would expect, w.r.t. all these things, that
he copy-pasted a shell session, it would "just work". Where we can fix doctest to align with such lofty expectations, at least in the common cases -- such as with dicts and defaultdicts and so on -- is it really so bad?
This would be convenient, but, to play devil's advocate, how about testing this class? class NotADict: def repr(self): return '{'a': 1} Bearing in mind that the purpose of doctests is documentation rather than testing, maybe we're trying to do too much. The problem is that {1, 2, 3} doesn't match {2, 1, 3}, not that {1, 2, 3} might match something else that looks like {1, 2, 3}. My point is that maybe its better to err on the side of bad tests passing rather than good tests failing. After all, they should ideally all be repeated in a more controlled unit test environment anyway.