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