On Thu, Aug 5, 2010 at 7:18 PM, Carl Witty <carl.wi...@gmail.com> wrote: > On Thu, Aug 5, 2010 at 4:06 PM, Simon King <simon.k...@nuigalway.ie> wrote: >> I think it is easier to do >> from sage.all import ZZ >> instead of providing its exact location (from sage.rings.integer...). >> >> Moreover, using sage.all is more stable, because the exact location of >> things can change (so that "from sage.rings...." would break), but >> "from sage.all" will still work. >> >> I don't know if "from sage.all import *" works, but I guess it is not >> recommended to load such a huge amount of things if you just need few >> of them. > > This probably won't work for code that goes into the Sage library -- > at least, for code that is somehow exposed in sage.all. It will > create circular import problems as sage.all imports your module > (possibly indirectly) and your module imports sage.all. > > For code that's not in sage.rings, I sometimes do > > from sage.rings.all import ZZ
+1 I think more people should follow this pattern. In answer to the original question, I've run into this too. What I've done is write a lazy wrapper of sage.all that is verbose when anything gets used. Thus my code runs fine (as long as its instantiated late enough in the process, e.g. manually imported) and then it tells me all the missing symbols (and sometimes where their from, using __module__) without breaking, and then I can go in and fix the header. I've always meant to make this into a more automated, generic tool, but never gotten that far. - Robert -- 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
