On Jun 24, 5:43 pm, kcrisman <kcris...@gmail.com> wrote: > You may want to see ifhttp://trac.sagemath.org/sage_trac/ticket/7496 > affects this, or whether it at least gives an idea of what to do. > preparse_file versus preparse was an interesting distinction I wasn't > previously aware of.
Thanks! implicit symbolic functions have nothing to do with it! I thought strange things were happening with Integer(1)=Integer(5) but that is not the issue. It's much more fundamental. preparse_file parses "1=5" as _sage_const_1 = Integer(1) _sage_const_5 = Integer(5) _sage_const_1 =_sage_const_5 so it's actually a frighteningly faithful translation of the original statement. The problem (as I'm sure Tom already knew) is that the preparser replaces something that is illegal as an L-value by something that is legal as an L-value, thereby turning code that should be ungrammatical into grammatical code. In order to fix this, it looks like you might actually have to parse the text. Try to predict what the following piece of code produces: [1^2 for j in range(10) for 1 in [1..2*1] ] -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
