On Mon, Oct 27, 2014 at 10:57 AM, Volker Braun <vbraun.n...@gmail.com> wrote: > On Monday, October 27, 2014 5:32:12 PM UTC, Nils Bruin wrote: >> >> I don't think this would be easy to do with the current preparser. > > As you said, we'll need to look at the AST. That is part of IPython's > preprocessing framework, trivial to implement.
It's not a question of ease, it's a question of desirability. Ideally most pre-parsing shouldn't change a valid Python AST. >> Furthermore, I think it is a strength of computer algebra systems such as >> sage, magma, maple that their interface language is also used for large >> parts of their libraries. This already doesn't quite hold true for sage, but >> apart from "1/2" and "2^3" it's confined to syntax that produces errors in >> straight python. I suspect that changing the semantics of "==" between >> interface and library will be much more subtle and hence more problematic >> (because casual testing may well not find differences). > > I don't think its that difficult. Library generally works with elements of > the same type, so you'll probably get away with not coercing in a lot of > places. It is mostly useful for handling user input, where you might want to > convert anyways. And if you don't then it will be rather obvious, if > Integer(1) works but int(1) doesn't then your comparison was too strict. > Doctesting can check that. > > Really its just a matter of replacing a == b in the library code with > is_isomorphic(a, b) in the right places. If we are smart about the > transition (supporting both old- and new-style comparison for a while) then > we could add that pretty gradually. Currently, the only place preparsing modifies valid code is for literals, which is surprising enough but at least easy to explain. Changing the meaning of == depending on the context is a really scary proposition to me. I would also argue that equality "across parents" is the Pythonic choice: sage: int(1) == float(1) True > The alternative is to not have caching and associative containers for > padics. That means you can never write Buchberger's algorithm for > polynomials with padic coefficients, say. I find that much more worrisome. We should make it easier to have associative containers with this notion of comparison if that's the crux of the issue, e.g. compare on (parent(a), a) rather than just a. I would even consider making elements by default unhashable by default, and one would have to write cache[a.key()] or cache[a.isomorphic_key()] to use them as keys. You have to be careful anyways storing things like p-adics or reals... - Robert -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
