On Thu, Dec 14, 2017 at 12:01 PM, John Cremona <john.crem...@gmail.com> wrote:
>
>
> 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".
To be clear, the code I wrote above specifically pertains to dicts
that are embedded in the __repr__ of some object. In other words,
that code goes in the __repr__ implementation, not the example/test.
This ensures that such objects are always displayed predictably.
--
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.
