That syntax, as well as adding the option for an explicit pathname
were discussed.
> With the "import x as y" syntax, authors would be free to make the
> global names of their modules long and descriptive. For example, I'm
> developing a URI module, but I suspect other folks are to. I'd like
> to be able to distribute it as, e.g. "connolly_uri.py" and have folks
> write:
>
> import connolly_uri as URI
>
> abc = URI.absolute('http://host/foo/bar')
> fp = abc.open()
>
In any case, "import x as y" is just shorthand for "import x; y=x; del x;"
Or:
import connolly_uri
URI = connolly_uri
abc = URI.absolute( 'http://host/foo/bar' )
[ and if I make the change to importmodule() to not require an
explicit pathname, then "URI=importmodule( 'connolly_uri', 'URI' )"
will also be a functional replacement with no added syntax. I
*would* like to figure out how to get rid of the redundant "URI"'s
on both the LHS and RHS of the statement. ]
The import from an explicit pathname was more awkward. At least the
trick of sourcing the module into a new scope with execfile() packages
it up into a reusable function, rather than having the "magic" hacking
at sys.modules visable ( and ugly. )
The original need for that arose when I wanted to replace module
'ftplib' with code that inherited from module 'ftplib'.
If you wanted connolly_uri to extend and replace module URI in
all of the code that imported URI you could name IT URI.py and
place it in a directory searched before the library where the
original URI.py lived. But then if you need to import the OLD
URI.py from within the new module, you were out of luck.
I previously posted an ugly hack that temporarily modified
sys.path and sys.modules from within the new module, so it
could successfully import the old module.
The new function is, I think, a definite improvement.
As I remember it, the "import module as name" was not controversial,
as far as the syntax ( except perhaps from the POV of not wanting
to add "as" a another reserved word. ). The sticking point on
an explicit pathname version was how to keep from making it
too os dependent: whether to adopt posix style pathnames and
translate them to local for non posix systems, or to adopt some
neutral syntax, or to allow any string valued expression - which
might have been the best approach, but probably would have been
non backwards compatible. So I think the whole thing got dropped
due to no consensus.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics