Quoth Mudcat <mnati...@gmail.com>:
> [attribution omitted by Mudcat]
> > I think you've probably had issues with circular imports (i.e. mutual
> > dependencies), unless you can precisely remember what you were doing and
> > what went wrong.
>
> That's possible, but circular imports become more of a hazard if you
> have to import in several locations. Unify that to one file, and those
> problems are much easier to avoid.
Personally I've never run into circular import problems when importing
library functions. Then, again, I always use 'from x import y' (or
'y as z' for those modules that use non-unique names for things, like
os.path.split).
Where I've run into circular import problems when when _my_ modules
were circularly importing things. Which just meant that my code needed
some refactoring.
> > I can make up three or four different logical groupings in my
> > applications... so what is 'logical' could not be the same for everyone,
> > or from every point of view.
>
> That's not the point. The point is that multiple imports can be a
> limiting factor if the module imports don't happen to align with the
> model they'd like to use for their file layout.
I'm inclined to agree with you that organizing code around which other
modules it imports is (usually) not the optimal organization. But it is
worth _considering_, because sometimes it does reveal a useful pattern
to refactor by.
> However playing around with the files, I guess it is possible to
> create a file that just does imports and then reference them all just
> like you would any other extension of the namespace. I created a file
> called imports and was able to access the sys module within it by
> importing all from imports and calling sys. That way at least all you
> have to do is import the one file each time.
If you are talking about making a file and then doing from X import *,
I'd shudder a little bit looking at such code. It just doesn't feel
like the python way :). Which doesn't mean you shouldn't do it, if it
works for you, it is more of a personal preference thing.
What I'd respond to better (and I almost started doing this in my
code...but it's more typing so in the end I didn't) is to have a module,
say 'lib', and just do 'import lib'. Then everything is called through
'lib': lib.os.path.split('/some/path'), etc, etc.
The difference is that that is explicit. If I'm reading your code
and I see that, I look at the top and I see the import for 'lib', and I
know to look for a lib module. If you use the from X import * pattern,
I lose that ability. Sure, I can look at the top, and see the 'from X
import *', and if that's the only 'from *' import I can guess that the
functions not defined in the file come from that one...but all of that
takes more brain cycles. It just doesn't feel as clean :)
But, in the end, it is mostly personal preference. I'm sure there are
Pythonistas out there whose lips will curl when seeing
'from os.path import split as pathsplit, join as pathjoin' in my code :)
--RDM
--
http://mail.python.org/mailman/listinfo/python-list
