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.

-- 
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.

Reply via email to