import sympy imports too much
Ronan Lamy
Running 'python bin/sympy_time.py', I realised that importing sympy
pulls in a lot of stuff that are irrelevant to an end user, like pdb,
doctest or py.test. Fixing this simply requires removing the imports of
runtests and pytest from sympy/utilities/__init.py and importing those
modules explicitly where they are required.
More generally, I've often been annoyed by the fact that it's impossible
to import only part of sympy and by the sheer amount of bloat in the
sympy namespace (len(dir(sympy)) == 497), so I'd rather like that we
start exercising some restraint in what we put in the "__init__.py"s.
What do you think?
Ronan
Ondrej Certik
> Hi all,
>
> Running 'python bin/sympy_time.py', I realised that importing sympy
> pulls in a lot of stuff that are irrelevant to an end user, like pdb,
> doctest or py.test. Fixing this simply requires removing the imports of
> runtests and pytest from sympy/utilities/__init.py and importing those
> modules explicitly where they are required.
This should be done.
>
> More generally, I've often been annoyed by the fact that it's impossible
> to import only part of sympy and by the sheer amount of bloat in the
> sympy namespace (len(dir(sympy)) == 497), so I'd rather like that we
> start exercising some restraint in what we put in the "__init__.py"s.
Yes, definitely.
>
> What do you think?
I think that the main "sympy" module should provide some reasonable
set of tools, right away. Maybe we can remove some things from the
global namespace into modules.
For specialized things, one should import things explicitly. For
example the physics quantum code needs to be imported from
sympy.physics.hydrogen and so on.
Ondrej
Aaron Meurer
common functions are imported by default, but if you want more
advanced things you have to import the module? The difficulty, the
common functions and more advanced ones might be in the same file.
So, for example, you might want to import dsolve() by default, but not
classify_ode() (similar to how dsolve() is imported by default in
Maple, but to use odeadvisor(), you have to do with(DETools)), but
both live in ode.py. Does Python make it easy to do this sort of
thing, or at least has someone written something that makes it easy to
do?
Or another idea would be to just import ode (the module) into the
namespace, and then you just use ode.classify_ode(), or from ode
import classify_ode if you are going to use it a lot. Or does this
take just as much time as importing into the global namespace in the
first place?
Also, I have heard that it might be possible to do lazy importing, so
for example, you don't actually import all the internal functions in
ode.py until someone calls dsolve(). You should be able to do some
magic using __import__() in either case, right?
Can we do more advanced benchmarks to see which modules are slowing
the import time down the most?
Aaron Meurer
> --
> 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+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
Aaron Meurer
default, if that helps.
Aaron Meurer
Ondrej Certik
> How difficult would it be to provide a model like Maple, where the
> common functions are imported by default, but if you want more
> advanced things you have to import the module? The difficulty, the
> common functions and more advanced ones might be in the same file.
> So, for example, you might want to import dsolve() by default, but not
> classify_ode() (similar to how dsolve() is imported by default in
> Maple, but to use odeadvisor(), you have to do with(DETools)), but
> both live in ode.py. Does Python make it easy to do this sort of
> thing, or at least has someone written something that makes it easy to
> do?
We need to experiment. I think we all agree that something like you
describe is desirable to do.
I think that basic "import sympy" should only import the core, plus
some basic functions, and then limits, integrals, solve, dsolve. Maybe
some more things.
And the rest should simply by not imported at all, and the user has to
import it by hand. That means, that dsolve() has to import the stuff
from withing the function itself, so that it gets "lazy imported".
>
> Or another idea would be to just import ode (the module) into the
> namespace, and then you just use ode.classify_ode(), or from ode
> import classify_ode if you are going to use it a lot. Or does this
> take just as much time as importing into the global namespace in the
> first place?
>
> Also, I have heard that it might be possible to do lazy importing, so
> for example, you don't actually import all the internal functions in
> ode.py until someone calls dsolve(). You should be able to do some
> magic using __import__() in either case, right?
>
> Can we do more advanced benchmarks to see which modules are slowing
> the import time down the most?
I do that usually by commenting out things in the sympy/__init__.py.
The problem is that sometimes things are interrelated, so one needs to
be a bit careful.
Ondrej
Ondrej Certik
> On Thu, Nov 11, 2010 at 1:08 PM, Aaron Meurer <asme...@gmail.com> wrote:
>> How difficult would it be to provide a model like Maple, where the
>> common functions are imported by default, but if you want more
>> advanced things you have to import the module? The difficulty, the
>> common functions and more advanced ones might be in the same file.
>> So, for example, you might want to import dsolve() by default, but not
>> classify_ode() (similar to how dsolve() is imported by default in
>> Maple, but to use odeadvisor(), you have to do with(DETools)), but
>> both live in ode.py. Does Python make it easy to do this sort of
>> thing, or at least has someone written something that makes it easy to
>> do?
>
> We need to experiment. I think we all agree that something like you
> describe is desirable to do.
>
> I think that basic "import sympy" should only import the core, plus
> some basic functions, and then limits, integrals, solve, dsolve. Maybe
> some more things.
>
> And the rest should simply by not imported at all, and the user has to
> import it by hand. That means, that dsolve() has to import the stuff
> from withing the function itself, so that it gets "lazy imported".
For example the special functions should *not* be imported by default,
as there will be tons of them. And one will just do:
from sympy.special import Ylm
and so on. That should be easy to do.
Ondrej
Ronan Lamy
> On Thu, Nov 11, 2010 at 11:59 AM, Ronan Lamy <ronan...@gmail.com> wrote:
> > Hi all,
> >
> > Running 'python bin/sympy_time.py', I realised that importing sympy
> > pulls in a lot of stuff that are irrelevant to an end user, like pdb,
> > doctest or py.test. Fixing this simply requires removing the imports of
> > runtests and pytest from sympy/utilities/__init.py and importing those
> > modules explicitly where they are required.
>
> This should be done.
https://github.com/sympy/sympy/pull/30
> >
> > What do you think?
>
> I think that the main "sympy" module should provide some reasonable
> set of tools, right away. Maybe we can remove some things from the
> global namespace into modules.
>
+1
> For specialized things, one should import things explicitly. For
> example the physics quantum code needs to be imported from
> sympy.physics.hydrogen and so on.
>
> Ondrej
>
There a few rather self-contained subpackages that shouldn't be
imported, then. These are physics, geometry and galgebra. It seems more
difficult to compartmentise all the mathematical stuff (e.g. N-theory
might seem to be an advanced and specialised topic but we certainly need
primality testing everywhere).
Aaron Meurer
It sounds like we need one of those packages that draws an
interrelationship graph of all the modules.
Aaron Meurer
Vinzent Steinberg
> It sounds like we need one of those packages that draws an
> interrelationship graph of all the modules.
>
> Aaron Meurer
Vinzent
[1] http://www.tarind.com/depgraph.html
[2] http://www.tarind.com/py2depgraph.py
Aaron Meurer
Aaron Meurer
Vinzent Steinberg
> Can you get that to work with SymPy. I just got a traceback.
Vinzent
[1] http://code.google.com/p/sympy/issues/detail?id=2103