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 slip by. 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.
p.s. according to https://trac.sagemath.org/ticket/23586 it will help a lot if we upgrade ipython to a version where https://github.com/ipython/ipython/pull/10767 is merged before switching to py3. I do not know wether this has been done already on some other ticket. On Wednesday, 6 December 2017 16:07:03 UTC+1, Erik Bray wrote: > > On Wed, Dec 6, 2017 at 3:59 PM, Jeroen Demeyer <jdem...@cage.ugent.be > <javascript:>> 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 in their output). This can fail from time to time since dict > >> element order is not guaranteed. > > > > > > In doctests, the output of dicts is sorted. So I guess you run into > trouble > > only when > > > > (A) The dict is embedded in some deeper structure: no general solution, > a > > case-by-case fix is needed > > > > (B) The sorting is different in Python 2 and Python 3: this is a general > > consequence of the __cmp__/__richcmp__ differences. One important ticket > is > > https://trac.sagemath.org/ticket/22029 > > > > (C) The keys cannot be sorted: fixed by > > https://github.com/ipython/ipython/pull/10767 which is not in Sage yet. > > > > I would not try to fix cases (B) and (C) in doctests because they will > be > > fixed at some point anyway. > > Aha, thanks for the summary of the current state of affairs. I didn't > realize plain dicts were already sorted in their repr--that is good. > > In that case probably most of the examples I've encountered are indeed > with more nested data structures. I'd have to double-check but that > sounds right for the examples I can think of off the top of my head. > > I think then for (A) the most general solution would be the one I > suggested--of basically scanning for dict literals, parsing them, and > reordering them. This isn't too hard in most cases; the only concern > might be if there are any cases of output that looks exactly like a > dict literal but for some reason isn't, and shouldn't be messed with. > I don't know that there are any cases like that though. > -- 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.
