Allow import ... from ... notation


import staff from module

syntaxes in addition to usual

from module import stuff

I often need import stuff from a module, so I write code like this

from pocket import ring

# some code using ring

As my code grows, I often realise that I need to import more stuff from the same module, so I change my code into.

import pocket

# some code using pocket.ring, pocket.nothing, pocket.hand

As Im finishing my code, I sometime come to conclusion that I dont need any other stuff from the module, so I clean my code back into

from pocket import ring, nothing, hand

# some code using ring, nothing, hand

I make these edits back and forth multiple times during the development. Each of this edits require me to flip the order of import and pocket, which requires copy-pasting or deleting-and-rewriting the symbols. Therefore, I suggest to allow writing

import ring from pocket 


import ring, nothing, hand from pocket 

so the order of ring and pocket would always remain the same, and I could save a few keystrokes

Cost/Benefit analysis
I do realise that the benefits from my suggestion are extremely small, but cost should not be very hight either, right? The implementation should not break anything, does not add anything new…

My hope is that the rest of the developers will come out saying “damn, I hated the same thing all along, lets change this!”

When you see a line starting import pocket, you immediately know it’s importing a module.

If you saw a line starting import ring, nothing, hand, you’d assume that it was importing a number of modules, but then you’d see the from pocket tacked on the end and you’d realise that those weren’t modules at all, but items from a module called pocket and you’d change it to from pocket import ring, nothing, hand anyway to make it clearer.


My concern is that having two ways to do the same thing adds complexity and reduces consistency.


Have you considered adding some macros to your editor?

1 Like

I don’t like the “from a import b, c” syntax because it doesn’t align nicely with “import a”. Plus, “from a import b, c” also binds the name “a”, which is weird from the look of it.

I’d prefer something like “import a (b, c)”, though the particular syntax needs to be considered to make it look nice.

In practice I just live with “from a import b, c” because it gets the job done, and elegance is less important.

The drawback with “import b, c from a” is that when you type it, the editor cannot “autocomplete” the b and c before you type a. That’s inconvenient.

I don’t think that’s correct.

>>> from math import pi

>>> math

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

NameError: name 'math' is not defined

1 Like

Thanks for the correction. You’re right.

That I observe “from a import b, c” binds “a” is not a result of “import” but a result of “a” being a filename (together with other conditions I have not attempted to sort out).

I’m pretty sure that’s not a thing either, at least as stated. Can you
produce an example of what you’re describing for us to try?

Cameron Simpson

Sure, please find an example below.

You need to create three files in the following structure:

    demo/ contains:

from ._impl import f, g
h = _impl.h  # <-- why is the _impl name available here contains:

def f(): return "how"
def g(): return "are"
def h(): return "you" contains:

import demo
print(demo.f(), demo.g(), demo.h())

Now from the work directory, run the following:


and you should see the output

how are you

Sure, please find an example below.

Thank you, this is a great example. contains:

from ._impl import f, g
h = _impl.h  # <-- why is the _impl name available here

This was a surprise to me.

I think this is because this import imports as the module
demo._impl and something in the import machinery annotations the
demo module with the name _impl to make demo._impl a working name.

Again, this is a surprise to me and I’m having trouble finding
documentation of this behaviour. I expect the import to define the
sys.modules["demo.__impl"] module entry, but I didn’t expect it to
define the name _impl in the demo module namespace.

So I think you get the name _impl because you’re in demo (i.e.

So the import statement is not writing _impl into whatever namespace
is running the import, it’s writing the name _impl into the demo
namespace, regardless of where the import statement was.

Here’s a showing this:

 from demo import h
 print("we have h:", h)
 print("we do not have demo:", demo)

and running it:

 [~/tmp/demo]fleet2*> python3
 we have h: <function h at 0x10392c790>
 Traceback (most recent call last):
   File "/Users/cameron/tmp/demo/", line 3, in <module>
     print("we do not have demo:", demo)
 NameError: name 'demo' is not defined

So the import statement not making a local demo name. You only saw
_impl in the previous example (demo/__init__py) because the demo
namespace is the local namespace when you were running that partiular
bit of code.

Cameron Simpson

That does make some sense. Consider:


One would expect the print to succeed (and print the repr of a module, not particularly useful). As such, whatever object foo is needs to be able to locate bar.

It’s a little surprising inside itself, but I don’t think there’s any good way around that, unless import demo._impl were to be actually disallowed in some way.

1 Like

Yes. I’ve been thinking about this and you’ve put into an example what I’ve been trying to formalise .

1 Like

As someone who is using both Python and JavaScript/TypeScript, which uses import { ... } from ..., I find Python’s syntax much more convenient. With Python you can just start typing and auto completion will just work. With JS/TS you have to start writing import {} from 'whatever', then move the cursor back between the braces for auto completion to work. That’s quite annoying. Python made the better choice here.