To me, the relevant concept seems to be software coupling, as railed against by structured programming gurus in the 1970s and 80s.
Having imports which know exactly where a symbol is defined, increase the knowledge that one part of our code has of other parts. Coupling is often unavoidable, but always comes with a cost. In this case, the added coupling is pretty minor, but I would still tend to vote against a global change. I don't use an IDE, but isn't finding definitions of symbols one of the basic features? (Or just use an emacs tags file, if you are feeling retro.) On Sunday, January 11, 2015 at 11:47:04 AM UTC-8, Joachim Durchholz wrote: > > Am 11.01.2015 um 19:12 schrieb Aaron Meurer: > > The other con is that if the function is moved (say, split out into a > new > > file), you have to change every other file that imports it. > > I agree it's a con (and one I overlooked because I incorrectly thought > it's already covered under (22), quoted below for reference). > > I do not think it's a large one. If a name's definition is moved, it's > easy to do a global search for all occurrences of the original package, > with a regular expression of > from old\.package\.name .* moved_name > (I'm usually lazy and leave the backslashes out, the false positives > that this causes don't happen in practice :-) ) > > The overhead is going to be partly made good by less merge conflicts in > the import statements, because imports tend to get split up (that's a > pro I forgot :-) ) > Also, in those import statements that list just a few names (and there > are more if the imports get split up), you usually don't have to split > up the line further, you just fix the name of the module you import > from. That's another small reduction in overhead. > > The overhead isn't going to go away of course, and in large-scale > refactoring, it can still become annoying. > > >> 22) Contributors might not want to have to hunt down the origin of > every > >> symbol that they want to import. > >> The good news is that if they import from some other module than the > one > >> that defines the name, they'll get a message that tells them where to > >> import from directly. > >> E.g. this: > >> -- > >> Error in $SYMPY/sympy/series/tests/test_limits.py line 3: Name 'log' > >> should be imported from module 'sympy.functions.elementary.exponential' > >> but is imported from module 'sympy'. > >> -- > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/d744df4d-cba6-4d0d-b3cf-4163f502a3b5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
