On Mon, Aug 7, 2017 at 5:14 PM, Vincent Delecroix <20100.delecr...@gmail.com > wrote:
> On 07/08/2017 23:11, David Roe wrote: > >> On Mon, Aug 7, 2017 at 5:03 PM, Vincent Delecroix < >> 20100.delecr...@gmail.com >> >>> wrote: >>> >> >> On 07/08/2017 22:53, David Roe wrote: >>> >>> On Mon, Aug 7, 2017 at 4:37 PM, Vincent Delecroix < >>>> 20100.delecr...@gmail.com >>>> >>>> wrote: >>>>> >>>>> >>>> On 07/08/2017 19:47, David Roe wrote:> But I think that Sage >>>> >>>>> >>>>> integers should compare the same as python ints >>>>> >>>>>> >>>>>> I agree and with Python 3 you get an error >>>>>> >>>>> >>>>> $ python >>>>> Python 3.6.2 (default, Jul 20 2017, 03:52:27) >>>>> [GCC 7.1.1 20170630] on linux >>>>> Type "help", "copyright", "credits" or "license" for more information. >>>>> >>>>> sorted([1,2,'a']) >>>>>> >>>>>>> >>>>>>>> Traceback (most recent call last): >>>>>>> >>>>>> File "<stdin>", line 1, in <module> >>>>> TypeError: '<' not supported between instances of 'str' and 'int' >>>>> >>>>> which is even better. >>>>> >>>>> >>>>> Sure, and I'm fine with that change once we switch to python 3 (or if >>>> we >>>> make that change actually true for Sage integers). But in the mean >>>> time, >>>> I >>>> think that we should keep compatibility between ints and Integers, which >>>> means adjusting the comparison with strings. >>>> >>>> Which still leaves the second part of Stefan's question: how do we get >>>> consistent doctest output in contexts where we have been sorting? >>>> >>>> Perhaps the right answer is to add a tag to the doctest framework. >>>> Something like >>>> >>>> sage: [1,2,'a'] # unordered >>>> ['a',2,1] >>>> >>>> >>> Introducing a new tag is too much pain. You are asking for the order of >>> something that have no natural order. I would just do >>> >>> sage: set(l1) == set(l2) >>> True >>> >> >> >> That doesn't work if the entries aren't hashable, and also doesn't show >> the >> entries, which can be a problem if you're also trying to document the >> function for users. >> > > You mean documenting a bad practice!? What bad practice are you referring to? The output of some functions are lists where the ordering is somewhat unpredictable. This different ordering can reveal itself in testing on different platforms, or with a changed package that Sage depends on. Yet for a user looking at the examples of using such a function, it's nicer to see sage: my_func(inputs) # unordered [A, C, B] rather than sage: set([str(c) for c in my_func(inputs)]) == set(["A","B","C"]) True David > > > -- > 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.
