On 14 December 2017 at 10:57, Erik Bray <erik.m.b...@gmail.com> wrote:
> On Wed, Dec 13, 2017 at 3:23 AM, Maarten Derickx
> <m.derickx.stud...@gmail.com> wrote:
> >
> >
> > 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> wrote:
> >> > On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky <
> mic...@orlitzky.com>
> >> > 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.
>
> Yeah, I see now that pprint (and its underlying pformat) print dicts
> sorted. I've already started using that for some cases and it seems
> to get the job done. My only annoyance is that it's very oriented
> toward terminal printing, and there's not a great way to control how
> lines are wrapped (or force it not to be multi-line) short of setting
> the width argument very large. So I've resorted to doing `'
> '.join(pformat(my_dict).splitlines())` which gets the job done but is
> a little ugly.
>
Indeed it is -- fine for a test but not in an "Example".
For a test/example which computes a dict which we expect to be
expected_value (in some sorting) why not put
sage: actual_value = ....
sage: actual_value # random order
sage: assert actual_value == <expected_value>
so we see the display, the test doesn't care about how it looks, but we
also test that it is correct without cluttering up the documentation.
>
> --
> 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.
>
--
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.
