On Tuesday, 12 December 2017 15:30:39 UTC+1, Erik Bray wrote:
>
> On Fri, Dec 8, 2017 at 10:10 AM, Erik Bray <erik....@gmail.com
> <javascript:>> wrote:
> > On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky <mic...@orlitzky.com
> <javascript:>> wrote:
> >> On 12/06/2017 09:49 AM, Erik Bray wrote:
> >>>
> >>> Did anyone ever think up a better solution to this?
> >>>
> >>
> >> Whatever you do, you wind up with a big pile of dict output in the
> >> middle of your test case. So (where possible) you might as well use
> that
> >> space to define a new dict containing the expected value. For example,
> >>
> >> >>> actual = some_computation()
> >> >>> expected = { 1: "one",
> >> ... 2: "two",
> >> ... 9: "nine" }
> >> >>> actual == expected
> >> True
> >>
> >> That's harder to do when the dict is buried in some other data
> >> structure, but maybe we shouldn't be testing the exact string
> >> representation of some big conglomerate in the first place -- do we
> >> actually care what it is? Instead, we should test only what we care
> about.
> >>
> >> Regardless, I don't think the framework should make it look like you
> can
> >> rely on dicts being sorted when you can't. Users should be able to run
> >> the EXAMPLES and see what we say they'll see.
> >
> > That is a good thing and a bad thing about so many of the tests
> > doubling as "examples" in the documentation (especially for 'public'
> > methods to the extent that there is such a thing). You want them to
> > actually function nicely as examples of how a user should use an
> > interface and what a user should expect to see. Going into
> > contortions in order to make it function reliably as a test can be at
> > odds with that.
> >
> > If we're talking one dict it's not much of a problem. The main
> > problem seems to be with more complex objects that contain dicts
> > nested in their reprs. And you do sometimes want to test the repr
> > string itself too (that, however, could be in the form of a TEST not
> > an EXAMPLE).
>
> Another workaround that's so obvious I smacked myself on the head is
> that for many cases, particularly objects that have a small dict in
> their representation, is to simply change the __repr__ so that its
> dict is always displayed sorted. If the order doesn't matter anyways
> that it doesn't hurt to impose an order at least for the __repr__. I
> doubt there are many cases where this should have any performance
> impact either.
>
I think this is indeed the way to go. In fact this is what I was trying to
say with my remark "In more complicated data structures it is probably more
a sign of the complicated data structure not pretty printing itself in a
nice way (i.e. failing to pretty print the dicts it depends on) then
anything else.". Which I admit is a bit cryptic, but essentially suggests
your workaround because dicts are sorted when pretty printed.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
