Why not use import sage.rings.integer_ring as module_integer_ring. If the location changes, just change what it is imported as. On Tue, Apr 1, 2008 at 3:01 PM, Robert Bradshaw < [EMAIL PROTECTED]> wrote:
> > On Apr 1, 2008, at 1:50 PM, William Stein wrote: > > > > On Tue, Apr 1, 2008 at 1:36 PM, Robert Bradshaw > > <[EMAIL PROTECTED]> wrote: > >> > >> On Apr 1, 2008, at 1:23 PM, Gary Furnish wrote: > >>> Wierd circular import issues can (should) be solved with circular > >>> cdef imports. I think the easiest fix to crazy deps (group theory > >>> on calculus) might be to do something alone the lines of > >>> foo = None > >>> def importcrazydeps(): > >>> global foo > >> > >>> import sage.foo as localfoo > >>> foo = localfoo > >>> Then have sage.x.package import all package modules and sage.x.all > >>> import sage.package and then run importcrazydeps() on any function. > >> > >> Yep, I think such things should be handled manually rather than > >> adding special behavior and caching to import functions in Cython. > >> Note that of you do "cdef foo" then accessing foo in the global > >> namespace will be a C lookup. > >> > >> One problem is that then we will have all kinds of > >> importcrazydepsfor_x() functions at the end of sage.x.all, which > >> will > >> get longer and longer, until we have circular dependancies among > >> these, etc. > >> > >> > >>> Perhaps another approach would be in Cython with an import optional > >>> foo (does not throw an exception on failure). > >> > >> -1. Then it throws an error later on? It has to check every time? > >> > >> I think the longterm solution is to reduce the number of "from foo > >> import blah" (if you just do "import foo" and don't use foo, it will > >> handle it just fine), reduce the number of unneeded imports (e.g. > >> "from sage.rings.all import ZZ" which needlessly imports lots of > >> other stuff than ZZ), and perhaps set up a hierarchy (e.g. decide > >> which of groups or calculus should be imported first, and then if > >> you > >> need to go the other way do it via "late imports" of without the > >> "from" keyword. > > > > I'm not disagreeing but want to point out a potential drawback > > to the above suggestion. Let's say I'm writing my modular abelian > > varieties package (which I am right now). If I type > > > > from sage.rings.integer_ring import ZZ > > > > instead of > > > > from sage.rings.all import ZZ > > > > then my code will break if the rings directory is reorganized > > (and it does get reorganized sometimes, e.g., moving code > > into the polynomial subdirectory...). Thus typing > > > > from sage.rings.all import ZZ > > > > results in my modabvar package being more robust against > > changes in Sage. > > > > I am not claiming that is enough of a reason to not do > > from sage.rings.integer_ring import ZZ > > just that there are pros and cons to both approaches. > > This is a very good point. It's kind of related to the hierarchy > idea--one would hope that rings are all loaded before one starts > loading the modular forms stuff. > > Actually, this very statement has caused me many headaches in places > (not in the modular directory) where importing ZZ from rings.all > imports a whole bunch of other stuff (e.g. algebraic reals) that in > turn imports the thing I'm trying to work on. rings.all is so huge it > might be worth having a rings.basic or something that just imports > ZZ, QQ, and maybe a couple of others. > > >> Sometimes it amazes me that the whole library manages to load at > >> all. > > > > It's even more amazing that it correctly runs 52 thousand > > lines of doctest input on a bunch of different platforms: > > > > was$ sage -grep "sage:" |wc -l > > 52637 > > :) > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
