I think it is entirely possible that fixing import problems may have to come at the expense of ease of use. I don't see rings.basic helping much. I envision grand discussions about what constitutes a basic ring and what should and should not be included. What happens if we still have issues after a rings.basic... do we move to a rings.basic and rings.basic2 system?
On Tue, Apr 1, 2008 at 3:14 PM, Robert Bradshaw < [EMAIL PROTECTED]> wrote: > > On Apr 1, 2008, at 2:08 PM, Gary Furnish wrote: > > Why not use import sage.rings.integer_ring as module_integer_ring. > > If the location changes, just change what it is imported as. > > I think the point is that re-arranging the rings directory should > have minimal impact outside of it. This is one of the big benifits of > an .all file. > > > > > 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 -~----------~----~----~----~------~----~------~--~---
