On Mar 2, 2012 8:55 AM, "Devin Jeanpierre" <jeanpierreda@gmail.com> wrote:
On Fri, Mar 2, 2012 at 7:36 AM, Steven D'Aprano <steve@pearwood.info>
wrote:
Still, I reckon a directive is the right approach.
Why? That's how I do it because I am/was paranoid about compatibility, but surely fixing dicts is important enough that, done right, nobody would object if the semantics of comparison change subtly to allow for unordered container comparison in the "natural" way?
(Is replying to a quoted quote acceptable on mailing lists?)
On Fri, Mar 2, 2012 at 12:56 AM, David Townshend <aquavitae69@gmail.com> wrote:
It seems that the problem with any solution based on interpreting repr (especially when nothing in know about the object) is that there are just too many exceptions.Another approach might be to allow for a custom compare function to be defined on doctest. E.g., in the module to be tested:
The definition/use of an alternate comparison function needs to be inside the doctests. Two issues:
Suppose we're running the doctests on module A, which defines a different compare function. Module B also defines a different comparison function, and is imported but not run as a doctest. Since both of them did a global set-attribute to set the comparison function, but B did it later, B wins and A's doctests are run under the rules for module B.
That was just a quick example of another approach to the problem. Sure, there are some issues to work out, but I don't believe this is an insurmountable problem.
Also, don't forget that doctests are quite often run in things that are _not_ python source files. In particular, tutorial-like documentation these days is frequently in the form of reStructuredText.
Once again, I'm sure we could find a way around this. Perhaps it would also be acceptable to define the compare function inside the docstring, or in this case inside a rst comment.
import doctest
def _compare(got, expected): return (sorted(eval(got)) == sorted(eval(expected)) or doctest.compare(got, expected))
doctest.usercompare = _compare
This function is wrong in the context of the above discussion. Why sort a dict or set? Worse, why sort a list or tuple? Like I said, this is just a quick example. Obviously the function body could look very different.
The compare function would only need to deal with the idiosyncrasies of types actually used in doctests in that module.
Punting it to a user-defined function is nice for _really_ crazy situations, but dicts and sets are not idiosyncratic or in any way exceptional. doctest itself should handle them the way a naive user would expect.
So what about, say, a defaultdict or a WeakSet? What exactly would a naive user expect?
-- Devin