On Fri, 2004-01-30 at 18:40, Armin Rigo wrote:
I don't use path hacks to find data files, but I have gotten into the habit of making data file directories packages when they live inside the source tree. Then I can just do
from my.package import data myfile = os.path.join(os.path.dirname(data.__file__), 'myfile.xml')
This is definitely a common idiom. I call the file path.py and yes, every top level script must import this before it imports any of the application's modules. We've been doing this kind of thing for years, and while I very often wish there was something we could put in the standard library, or hack we could add to the executable, there have really never been any elegant-enough solutions to the problem.
I never find myself using "import package.module" but always "from package import module". Actually I still have to be convinced that packages are a Good Thing. As far as I am concerned, sys.path hacks are the only case in which I miss a Python feature sufficiently to have to copy similar custom code all around my projects.
Two different things. Packages are a huge win IMO because it allows for larger organizing principles. Flat import space was really painful before packages came along. Things like distutils wouldn't be feasible without them, and we'd be arguing about naming conventions much more if we didn't have them.
That's aside from the path hackery necessary for top level application scripts. I use "from package import module" all the time and I think Python's rules here are just about right. Personally, my only complaint is the default-relative import rule.
A more radical point of view is that these sys.path hacks are here not because of a missing feature, but on the contrary to work around the way Python tries to isolate me from the "messiness out there" (the file system) by mapping it into a neat language construct (packages). Trying to map a user-controlled structure over another, different one is a receipt for eventual confusion, however good the design is.
I disagree. I really like the layer of abstraction Python imposes here and I'd hate to see that taken away. I'm -1 on any proposal to use (forward) slashes in import statements. To me, it's way to system dependent (wait 'til the Windows people push for backslashes). I also like the level of indirection, control, and flexibility that sys.path gives you. I agree it would be nice to not have to write autopath.py modules, but that only affects a handful of files in an otherwise large application.
Other than relative imports, the only other thing I occasionally miss in Python's import semantics is the fact that more than one file system space can't be mapped into one package namespace without trickery. E.g. if in "import my.package.sub1" and "import my.package.sub2", the directories sub1 and sub2 didn't have to live under a directory called my/package.
I think I'd prefer to have just a reasonably natural way to talk about modules -- and files in general -- relative to the current module or the standard library. This is only a vague idea, but I believe it would fit better into (at least my view of) Python's philosophy: keep the language simple by avoiding abstraction layers that are not "natural", i.e. that do some kind of remapping of concepts, as opposed to just expose a higher-level view of the same concepts.
I disagree that Python's current rules are not natural. I think they're very natural, modulo a few nits here and there. I definitely don't want to live closer to the metal in the import statement.