Am 18.07.2013 18:03, schrieb Aaron Meurer:
On Thu, Jul 18, 2013 at 9:05 AM, Joachim Durchholz <[email protected]> wrote:
I'm currently wrestling with what the import statements are actually doing.
Removing C means rearranging import statements, which often has unexpected
effects because stuff is installed in C but not yet installed to all module
dictionaries, so C.Expr works because it's executed long after all import
initialization but
import Expr from sympy.core.expr
does not.
Probably because that's not valid syntax :)
Nah, the syntax was right, the quote was wrong :-D
1. import from the defining module instead of from the standard module where
there is a problem.
If this works, then do it.
It does :-)
> The only issue is that it makes it more
annoying when people move functions around. For the most part in
SymPy, if you can "from sympy import something", then it is not worth
it to "from sympy.module.submodule import something" because pretty
much every submodule will do a complete import of SymPy anyway.
Yes, that can be annoying.
Don't know a good way around that.
An alternative approach would be to stick with "from sympy import blah",
but let the submodules install themselves into the higher-level
namespace. Something along the lines of
def blah(...):
...
sympy.__all__ += 'blah'
(making up syntax here) (maybe a wrapper would work for that)
There may be performance issues with this, but you'd have to profile
to find out (I'm not even sure which one should be faster, "from sympy
import something" or "from sympy.module.submodule import something").
Since it's all just map lookups, it's probably the difference between a
long and a short key. Once, during import.
I couldn't exclude indirect effects, though I doubt there are any.
2. Make it a rule in Sympy implementation code to always import from the
defining module.
I'm not convinced this would solve all the circular import issues, though.
It wouldn't.
It would help with diagnosing them though - you wouldn't have to check
all the __init__.py files and the code that's called from them to find
out what the dependencies are.
3. Use relative imports.
Actually, now that we have dropped Python 2.5 support,
Oh did we? I missed the final decision then.
> we can do "from
__future__ import absolute_import" and use either absolute imports or
.. style relative imports everywhere. I think we should do this,
because it removes issues that people sometimes have with things like
having a file named numbers.py that SymPy thinks is
sympy.core.numbers.
Good point.
I thought that most C uses could be solved by moving imports inside
functions.
Those with real cycles: yes.
I'd prefer to use normal importing where an inside-function import isn't
needed (see below).
> This may have performance issues, but we should profile
that.
Hm... well, it's going to suck if and only if the function in question
is being called in a tight loop.
That's nothing we can find out through profiling, because that's at the
discretion of the caller.
... hm well, okay, what we *can* profile is whether this has an impact
on a function that does very little other than the import.
If the impact is negligible even then, that would give us more design
alternatives.
Still, I'm of a static school (not the best mindset for Python, I know),
and I prefer to be able to see the dependencies at a glance in the header.
> We may also have to reorganize certain class attributes to be
properties (which they usually should be anyway, and it will make
import time faster, like at
https://github.com/asmeurer/sympy/commit/ae51bce37847fa7f5c909bd3865d19fd61542ea7).
Hm... that will make the import faster, but running a lambda each time
the property is read is going to make using it slower.
Maybe an instantiate-on-first-use thing would be in order.
Something like
_a = property(lambda self:
_a = sqrt(2)/sqrt(pi)
return _a
)
(I'm probably getting the syntax details wrong here)
--
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.
