On Thu, Jul 18, 2013 at 11:33 AM, Joachim Durchholz <[email protected]> wrote: > 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.
The final decision was made a while ago to keep support until 0.7.3, but that's been released since last week. All remaining support was removed in https://github.com/sympy/sympy/pull/2273, except for some the things mentioned in https://github.com/sympy/sympy/pull/2273#issuecomment-20853941 (relative imports being one of those things). > > >> 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). 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. > > >> 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. Importing can have a performance hit. See for example https://github.com/sympy/sympy/commit/769dccca81006fe6e0a3f71085241b3f85e6ff99. You're right that it only matters for functions that are called a lot, though (but _sympify is such a function). > > >> 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) No, it doesn't matter if it's slow when the class is used. The class attribute is rarely called. It's only called if those particular functions are used, and in that case, it is nothing compared to the rest of the algorithm. On the other hand, you can really feel even the smallest things at import time, because that multiplies up over various libraries to make loading things like pylab slower (and even without considering performance, running things like sqrt(pi) at import time make debugging the core a huge pain, because if sqrt(pi) raises an exception, then you can't even import sympy. This actually, not performance, was the true motivation behind that commit). Aaron Meurer > > > -- > 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. > > -- 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.
