Just to give you a practical example, we are using python for internal tools in the electronic Company I'm working for. I needed to have a non ambiguous file lookup when using import ( We set external dependencies for the flow when opening a file, so you can't use a 'if this file exist' check, when opening a file, it must always exists) I made a special import function, that was looking for a prefix to the package name: import loc.dotted.name import glb.dotted.name import __.dotted.name import std.dotted.name import xxx.dotted.name -> raise an error "loc", look in the current directory of the module (looking to his __file__ attribute) "__ "look to the parent directory "glb" look at the root of the user working repository ( a builtins set before anything else is done , users don't call python they the program myPython ) "std" look outside the database ( in the python installation dir mainly) and set back the old import behaviour to ensure that import inside standard modules don't fail ) I know the loc,glb __ and std names are no good for a general case as modules can have these names, but this is just to give you an actual use of these relatives imports. Boris Nick Coghlan wrote:
Greg Ewing wrote:
So I think we really want *three* kinds of module reference:
A: Explicitly absolute B: Explicitly relative to the current module C: Searched for upwards in the package hierarchy from the current module
(Note that C is a generalisation of the current "ambiguous" references which only look in two places.)
Alternate spellings (plus category D, which is "Python 2.3 semantics"):
A: from __absolute__.dotted.name import foo B: from __relative__.dotted.name import bar C: from __heirarchy__.dotted.name import foobar D: from dotted.name import barfoo
I believe this spelling would only require import to handle the special cases as the first 'package' name (although having the compiler recognise them may be a later optimisation), and should also work with straight "import __absolute__.dotted.name.foo" statements.
Then Guido's migration plan would apply to the progression of the D semantics from the Python 2.3 model to being a shorthand for the absolute semantics.
And once _that_ has happened, then we could get rid of the '__absolute__' version in the name of TOOWTDI.
Regards, Nick.