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