Proposal: Inline Import

[Mike Meyer]

Shane Hathaway <shane at hathawaymix.org> writes:
> Here's a heretical idea.

Not really.

> I'd like a way to import modules at the point where I need the
> functionality, rather than remember to import ahead of time.  This
> might eliminate a step in my coding process.  Currently, my process is
> I change code and later scan my changes to make matching changes to
> the import statements.   The scan step is error prone and time
> consuming. By importing inline, I'd be able to change code without the
> extra scan step.

As others have pointed out, you can fix your process. That your
process doesn't work well with Python isn't a good reason for changing
Python.

> Furthermore, I propose that the syntax for importing inline should be
> an expression containing a dot followed by an optionally dotted name.
> For example:
>
>    name_expr = .re.compile('[a-zA-Z]+')
>
> The expression on the right causes "re.compile" to be imported before
> calling the compile function.  It is similar to:
>
>    from re import compile as __hidden_re_compile
>    name_expr = __hidden_re_compile('[a-zA-Z]+')
>
> The example expression can be present in any module, regardless of
> whether the module imports the "re" module or assigns a different
> meaning to the names "re" or "compile".

It's actually an intriguing idea, but I'm going to have to give it a
-1.

The thing is, it's really only useful in a corner case - where you
want to refer to a module exactly once in your code. I'd hate to see
code that skips doing the import to do .re.compile a half-dozen times
instead of importing the name properly. In fact, avoiding this
situation just makes your process even worse: you'd have to go back
and scan for multiple uses of .module and fix the import statements.

> I also propose that inline import expressions should have no effect on
> local or global namespaces, nor should inline import be affected by
> local or global namespaces.  If users want to affect a namespace, they
> must do so with additional syntax that explicitly assigns a name, such
> as:
>    compile = .re.compile

You can do this now, with "from re import compile".

> In the interest of catching errors early, it would be useful for the
> Python parser to produce byte code that performs the actual import
> upon loading modules containing inline import expressions.  This would
> catch misspelled module names early.  If the module also caches the
> imported names in a dictionary, there would be no speed penalty for
> importing inline rather than importing at the top of the module.

No. No, no and no. That's -4, for those keeping count.

This is different from the semantics of the import statment, which
means your examples above are broken. This is a bad thing.

This means that some expressions are "magic", in that they are
automatically evaluated at compile time instead of execution
time. This is a bad thing.

I'm not sure what your cache would do. Modules are already cached in
sys.modules. Your implicit import would have to look up the module
name just like a regular import. The name following then has to be
looked up in that module - both of which are dictionary lookups. What
would you cache - and where - that would noticably improve on that?

> I believe this could help many aspects of the language:
> - The coding workflow will improve, as I mentioned.

I think it'll get worse.

> - Code will become more self-contained.  Self-contained code is easier
> to move around or post as a recipe.

If you really want to do this, use __import__.

> - There will be less desire for new builtins, since modules will be
> just as accessible as builtins.

I don't see people asking for new builtins often enough to think that
this is a problem that needs fixing.

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.