Am 21.07.2013 01:28, schrieb Aaron Meurer:
On Sat, Jul 20, 2013 at 6:23 AM, Joachim Durchholz <[email protected]> wrote:
(Bumping an unresolved issue)
You could also use bottom imports (moving the imports to the bottom of
the file), but frankly, I'd rather have imports inside functions,
unless the function is called enough that it's a performance hit.
I'm not seeing advantages here - what are they?
I see a disadvantage in that at least the parent class for any class
definition would have to be imported, so we'd now have two lists of imports,
one at the top, one at the bottom.
The disadvantage is readability. The advantage is that the import is
only run once, at import time.
As far as I can tell, each import is run the same number of times
regardless of whether it's imported at the top or bottom. The imported
symbols just aren't available to module code, i.e. to class and function
declarations.
I must be missing a part of the picture if bottom imports can prevent
module code from running more than once - what is it?
You'll also want to profile that, at least for stuff in the core.
What would be a good candidate?
E.g. a test that accesses a given property for a gazillion of times.
Yeah. Or just profile SymPy in general (that will give you an idea of
what is *actually* used, which a contrived example won't).
Not sure what you mean - importing sympy.*, or using Sympy?
Actually, both should probably be profiled.
I can profile the import already, no trouble with that (~2.8 seconds for
that on my machine if no disk access is required).
It's probably not very meaningful trying profile Sympy in full
generality. Quantum physicists wouldn't use number theory and number
theory specialists wouldn't use the QM modules.
However, I want to establish that lazily-initialized attributes don't
make Sympy any slower.
So I'll replace a single attribute with a lazily-evaluated one and run
some code that retrieves that attribute often enough to make the test
meaningful. Ideally, that would be some unit test, because then I
wouldn't have to code anything up.
Is there such a test?
This solves the problems for attributes of classes, but what about
stuff that's at the module level?
The technique is a function that
- computes a value,
- replaces itself with that value in whatever namespace it is living in,
- returns the value.
Properties don't work on modules, but the technique should be transferrable.
I doubt there are many module level variables that are not functions
anyway (except for all the ones that are classes).
Seems like everything is a class actually.
I made a list of things in C, with some diagnostics and a readymade
import statement.
Here's the code I used to make the list:
---
from inspect import getmembers, isclass, isfunction
from sympy import * # 309
# Now import all modules that
# - do not have .test or .benchmark in their name
# - can be imported as a module
# - actually increase the number of members in C
from sympy.combinatorics import * # 317
from sympy.physics import * # 318
from sympy.physics.quantum import * # 385
from sympy.stats import * # 455
from sympy.categories import * # 463
from sympy.diffgeom import * # 473
# This seems to be exluded but does not add to C
# import abc
print 'C member count:', len(getmembers(C))
for (key, value) in getmembers(C):
# Widths were determined experimentally
print 'C.%-30s %-50s' % (key, type(value)),
if hasattr(value, '__module__'):
module_name = value.__module__
if module_name == None:
print '(__module__ attribute is None)'
else:
# generate an import statement ready for copy&paste
# naively applying this can cause "cannot import" exception
# I have yet to find out why
print 'from', module_name, 'import', key
else:
print '(no __module__ attribute available)'
---
As far as I can tell, everything in C that actually needs to be imported
is a class.
I'd appreciate if somebody looked at the code to see whether I'm missing
anything, or at the output to see whether I'm getting
misleading/wrong/useless data.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
