On Tue, May 31, 2016 at 7:07 PM, Nils Bruin <nbr...@sfu.ca> wrote: > > On Tuesday, May 31, 2016 at 9:37:48 AM UTC-7, Volker Braun wrote: >> >> This was a request at sd74: >> >> sage: 42 mod 8 >> 2 >> sage: type(42 mod 8) >> <type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'> >> >> Thoughts? Ticket is at http://trac.sagemath.org/ticket/20735 > > > I can see a few negatives: > - confusion with "%" operator and with "mod" operators in other languages > (which are generally "remainder" operators) > - once we have it for integers, I am sure people would start to expect it to > work in other situations too (where preparsing is harder) > - the current implementation is a smart idea, but it's not "highest > precedence": 3^5 mod 2 > - you're introducing a new reserved word in sage, which will break previous > code. > - to be an infix operator, it has to respect parentheses, so (2+3) mod > (3*(7+8)^2-19) should work (and then we're down the drain again, because > regex isn't powerful enough for parentheses).
All the more reason Sage's preparser should be replaced with an actual parser, modified from the Python grammar (this was already suggested in one of the Python 3 threads, in the context of using lib2to3). An AST could first be generated using Sage's modified grammar, than transformed into a standard Python AST for passing through lib2to3 :) Best, Erik -- 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.
