Shane Hathaway <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
