aquavitae69 at gmail.com
Fri Mar 2 12:07:16 CET 2012
On Mar 2, 2012 8:55 AM, "Devin Jeanpierre" <jeanpierreda at gmail.com> wrote:
> > On Fri, Mar 2, 2012 at 7:36 AM, Steven D'Aprano <steve at pearwood.info>
> >> 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 at gmail.com>
> > It seems that the problem with any solution based on interpreting repr
> > (especially when nothing in know about the object) is that there are
> > 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
> 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
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
> -- Devin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas