On Dec 30, 2010, at 5:17 AM, Mateusz Paprocki wrote: > Hi, > > On 30 December 2010 08:49, Aaron S. Meurer <asmeu...@gmail.com> wrote: > > On Dec 30, 2010, at 12:42 AM, Ondrej Certik wrote: > > > On Thu, Dec 30, 2010 at 4:36 AM, Aaron S. Meurer <asmeu...@gmail.com> wrote: > >> OK. I have made the change. See https://github.com/sympy/sympy/pull/58. > >> > >> Some questions/concerns: > >> > >> - What is the purpose of the bottom imports (imports at the bottom of the > >> file) in some of the sympy/core files? I moved the from sympify imports > >> from the bottom to the top, but left the rest alone because I didn't know > >> why they were there. > > > > This is to avoid circular dependencies. Try to move it to top and run > > tests and you'll see. > > Right. > > > > >> > >> - I have added SympifyError to the list of things imported with from sympy > >> import *. Is this a good idea? It wasn't imported before, but it seems > >> to me that you should have these errors in the namespace so that you can > >> catch them. > >> > >> - Can/should I add a test for the fact that stdlib_symbol is no longer in > >> the main namespace? This isn't the first time we have had junk make its > >> way into the main namespace (see > >> http://code.google.com/p/sympy/issues/detail?id=1454). > > > > I don't have an opinion. If you think it's worthy, then let's do it. > > How do others feel about testing the global namespace? We would have to test > sympy.__dict__. > > > > >> > >> - I inserted from sympy.parsing import * in a place where it seemed to > >> work in the main __init__.py, but I don't know if this order matters for > >> things other than the order that it has to work in. > >> > >> - Why do we import init_session and init_printing into the global > >> namespace? > > > > I think so that one can initialize such sessions in raw Python > > interpreter. If you think these things don't belong there, feel free > > not to import them any more. > > Is it different from running "from sympy.interactive import *"? Again, how > do others feel about this? I myself am just getting tired of the slow import > time and want to remove superfluous things from SymPy's __init__.py's. > > For one user this is useless for the other it's useful, so this way we may > have hard time removing "superfluous" imports. But lets consider the use > cases. We have interactive sessions, where we would like to have all useful > stuff ready to use and non-interactive where we can afford writing explicit > or semi-explicit imports (from sympy.core.add import Add vs. from sympy.core > import Add) to import this useful stuff. Every user has he's own definition > of "useful stuff". Lets focus on interactive sessions. Personally, I use > IPython in 99.9% of cases and I hate importing stuff manually and I expect > all the common stuff + stuff related to my work already imported at > interpreter start, but I also don't like slow import times in both > interactive and non-interactive sessions. > > Lets assume we reduce from sympy import * to the bare minimum. Then we should > create another entry point, say sympy.all (or something), which would allow > us to write from sympy.all import * and get the current behaviour of from > sympy import *. Then we can add a switch to isympy, e.g. --all, which would > import from sympy.all on interpreter startup (or a configuration file for > sympy, which we should add sooner or later). I'm not sure about this, but in > IPython we could maintain a list of modules' imports and we may use some kind > of hook to catch NameErrors and ask the user what to do: (1) do nothing, (2) > import the name or (3) import everything from the module, or choose from > (1-3) automatically based on local sympy's configuration (a command-line > switch or configuration file). > > Implementing at least some of the above options, should give us short startup > times and make interactive usage of sympy less painful.
So it's basically lazy importing, right? This is an interesting idea. I wonder, though, if it will make a difference. I noticed when I was fixing the import statements for this issue that because of dependencies, by the time that it got past importing the core and importing the polys, almost everything else had already been executed. For example, the polys use factorial, which causes the functions to be compiled. I guess it depends on what takes a long time when importing: the compiling/running of module files, or moving those files into the namespace. Of course, we know that we can remove things like geometry and physics, which are not used by any other module. But anyway, when I said "superfluous," I was specifically referring to init_session, which is the exact same as from sympy.interactive import *. Actually, it is worse, because init_session being imported from "from sympy import *" implies that you have already imported everything, and so all it is doing then is setting up the printer and creating the x, y, z symbols. Aaron Meurer > > > Aaron Meurer > > > > > > Ondrej > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sy...@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > > Mateusz > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sy...@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
