[Python-ideas] Packages and Import
brett at python.org
Sun Feb 11 18:36:01 CET 2007
On 2/11/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> Josiah Carlson <jcarlson at uci.edu> wrote:
> > Anyways...I hear where you are coming from with your statements of 'if
> > __name__ could be anything, and we could train people to use ismain(),
> > then all of this relative import stuff could *just work*'. It would
> > require inserting a bunch of (fake?) packages in valid Python name
> > parent paths (just in case people want to do cousin, etc., imports from
> > __main__).
> > You have convinced me.
> And in that vein, I have implemented a bit of code that mangles the
> __name__ of the __main__ module, sets up pseudo-packages for parent
> paths with valid Python names, imports __init__.py modules in ancestor
> packages, adds an ismain() function to builtins, etc.
> It allows for crazy things like...
> from ..uncle import cousin
> from ..parent import sibling
> #the above equivalent to:
> from . import sibling
> from .sibling import nephew
> ...all executed within the __main__ module (which gets a new __name__).
> Even better, it works with vanilla Python 2.5, and doesn't even require
> an import hook.
> The only unfortunate thing is that because you cannot predict how far up
> the tree relative imports go, you cannot know how far up the paths one
> should go in creating the ancestral packages. My current (simple)
> implementation goes as far up as the root, or the parent of the deepest
> path with an __init__.py[cw] .
Just to make sure that I understand this correctly, __name__ is set to
__main__ for the module that is being executed. Then other modules in
the package are also called __main__, but with the proper dots and
such to resolve to the proper depth in the package?
> If you are curious, I can send you a copy off-list.
I have way too much on my plate right now to dive into it right now,
but I assume the patch is either against runpy or my import code?
More information about the Python-ideas