PEP: possibility of inline using of a symbol instead of "import"

[Carl Banks]

On Jan 6, 7:28 am, dmitrey <dmitrey.kros... at scipy.org> wrote:
> hi all,
> I have th PEP (I'm not sure something like that hadn't been proposed
> although):
> very often in a Python file header the following lines are present,
> like:
> from MyModule1 import myFunc1
> import MyModule2 as mm2
> from MyModule3 import myFunc3 as mf3
> etc
>
> and after several pages of code they are using somewhere, maybe only
> one time, e.g.
> r1 = myFunc1(...)
> r2 = mm2.myFunc2(...)
> r3 = mf3(...)
> It makes programs less clear, you have to scroll several pages of code
> in IDE to understand what it refers to.
>
> I propose to add possibility of using a symbol instead (for simplicity
> I use @ here, that is already reserved for decorators, thus it should
> be other symbol, maybe from Unicode although for simplicity to type it
> I would prefer something ordinary like $ or ` or !).
>
> e.g. instead of
>
> import MyModule
> (...lots of code...)
> r = MyModule.myFunc(...)
>
> someone could just type in the single place
>
> r = @MyModule.myFunc(...)
>
> Also, "import MyModule2 as mm2" could be replaced to mere
> mm2 = @MyModule2
> and "from MyModule3 import myFunc3 as mf3" could be replaced to mere
> "mf3 = @MyModule3.myFunc3".
>
> As for __import__(ModuleTextName), it could be replaced to something
> like @(ModuleTextName) or @{ModuleTextName} or @[ModuleTextName].


I actually wouldn't mind this; in fact Python's importing mechanism is
bad enough that a complete overhaul might not be a bad thing.

But, first of all, one can already do in-line imports in Python with
the __import__ built-in function (and I used to do this frequently in
throwaway scripts before list comprehensions were added).  For
instance, a one-liner to generate a password would be this:

python -c 'for i in xrange(8):
__import__("sys").stdout.write(__import__("random").choice(__import__("string").letters))'

Today a better way to do it would be like this:

python -c 'import random,string; print
"".join(random.choice(string.letters) for i in xrange(8))'

But that's a digression.

The problem with in-line imports is that it can lead to deadlock in
multithreaded programs, so for the most part it's a good idea to avoid
importing within functions.

Therefore, a syntax for it would really be needed to gain full
benefit.  This would allow the compiler to scan the file to collect a
list of prerequisite modules.  In my mind, the module itself wouldn't
import the dependencies itself, it simply lists prerequisites and
leaves it to the runtime to ensure that they've been imported.

A side benefit to this is to keep module namespaces clean.

Main drawback is that it makes accessing symbols in deepely nested
packages unwieldy (since presumably you'd have to write out the fully-
qualified name).  Meh, I pretty much avoid deeply nested packages, and
typically spell out the fully-qualified module names anyway.  So not
my problem.

As for listing imports at the top of the program--I can't say I have
much use for it.  Sometimes it helps to see a list of prerqequisites
in one place, but I can't say it's the most useful thing ever, and
anyway it's misleading since the imports can become stale.  I'd rather
not have to stop and scroll up ten pages to add an import to the top
of the module when I suddenly need to access time.sleep or
itertools.count.

So, pending a better syntax, I'll give it a +0; and the only reason I
don't give it a +1 is it's such a drastic change.

The syntax probably would deserve a lot of thought (being such a
drastic change) but drawing from C++ a postfix operator would seem to
fit.

sys:: -> evaulates to the sys module
sys::version -> evaluates to sys.version
xml::etree::ElementTree:: -> as expected

That has the unfortunate effect of making Python look like C++ though.


Won't ever happen though.


Carl Banks