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 -~----------~----~----~----~------~----~------~--~---
