On Fri, Dec 15, 2017 at 12:11 PM, Erik Bray wrote:
> On Thu, Dec 14, 2017 at 10:02 PM, Nils Bruin wrote:
>> On Thursday, December 14, 2017 at 3:29:32 AM UTC-8, Erik Bray wrote:
>>>
>>>
>>> To be clear, the code I wrote above specifically pertains to dicts
>>> that are embedded in the __repr__ of
On Thu, Dec 14, 2017 at 10:02 PM, Nils Bruin wrote:
> On Thursday, December 14, 2017 at 3:29:32 AM UTC-8, Erik Bray wrote:
>>
>>
>> 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 __re
On Thursday, December 14, 2017 at 3:29:32 AM UTC-8, Erik Bray wrote:
>
> 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
On Thu, Dec 14, 2017 at 12:01 PM, John Cremona wrote:
>
>
> On 14 December 2017 at 10:57, Erik Bray wrote:
>>
>> On Wed, Dec 13, 2017 at 3:23 AM, Maarten Derickx
>> wrote:
>> >
>> >
>> > On Tuesday, 12 December 2017 15:30:39 UTC+1, Erik Bray wrote:
>> >>
>> >> On Fri, Dec 8, 2017 at 10:10 AM, Er
On 14 December 2017 at 10:57, Erik Bray wrote:
> On Wed, Dec 13, 2017 at 3:23 AM, Maarten Derickx
> 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 wrote:
> >> > On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitz
On Wed, Dec 13, 2017 at 3:23 AM, Maarten Derickx
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 wrote:
>> > On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky
>> > wrote:
>> >> On 12/06/2017 09:49 AM, Erik Bray wrote:
>>
On Wed, Dec 13, 2017 at 5:15 AM, Michael Orlitzky wrote:
> On 12/12/2017 09:30 AM, Erik Bray wrote:
>>
>> 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 __r
I think that printing the result of bool(effective_result==expected_result)
is sufficient for testing purposes, and has the advantage of testing
mathematical equality, not only string equality.
You may want to be more explicit when failing : you may try (something
like) :
res=bool(effective_re
On 12/12/2017 09:30 AM, Erik Bray wrote:
>
> 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 or
On Tuesday, 12 December 2017 15:30:39 UTC+1, Erik Bray wrote:
>
> On Fri, Dec 8, 2017 at 10:10 AM, Erik Bray > wrote:
> > On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky > wrote:
> >> On 12/06/2017 09:49 AM, Erik Bray wrote:
> >>>
> >>> Did anyone ever think up a better solution to this?
On Fri, Dec 8, 2017 at 10:10 AM, Erik Bray wrote:
> On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky
> 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
>> m
On Thu, Dec 7, 2017 at 12:56 AM, Michael Orlitzky 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
>
> Users should be able to run the EXAMPLES and see what we say they'll see.
>
+1
--
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...@googl
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.
I strongly dislike the idea making the doctesting framework more
complicated by parsing the output like this. I think this should only be
done as a last resort, since it makes the doctesting framework itself more
error prone, and if implemented incorrectly might even silently let real
error sli
On Wed, Dec 6, 2017 at 3:59 PM, Jeroen Demeyer wrote:
> On 2017-12-06 15:49, Erik Bray wrote:
>>
>> I think this question has come up before, but I don't know that
>> there's been a really satisfactory solution.
>>
>> Many of the doctests have dicts as their output (or worse, contained
>> embedded
On 2017-12-06 15:49, Erik Bray wrote:
I think this question has come up before, but I don't know that
there's been a really satisfactory solution.
Many of the doctests have dicts as their output (or worse, contained
embedded in their output). This can fail from time to time since dict
element o
I think this question has come up before, but I don't know that
there's been a really satisfactory solution.
Many of the doctests have dicts as their output (or worse, contained
embedded in their output). This can fail from time to time since dict
element order is not guaranteed. This has been p
18 matches
Mail list logo
