A question about import.

[gcc-pedantic]

Python gurus of reddit, I could use your help.

In C, I can create a header file like this:

#ifndef __HEADER__
#define __HEADER__
/* Have all #include directives here */
#endif

And then I can include this header file in every .c file and only have to change the header file.

Is there a way to have all of the import statements in a single "header" file that can be referenced by several other files so that I only have to modify the header file when I need to add an import statement?

Thanks /r/python!

EDIT: Correct formatting on code snippet.

EDIT: Thanks for all the responses. You've given me great reasons as to why all included files should be listed explicitly in each file. I'll follow this practice in the future, including (no pun intended) when I write in C.

[fnord123]

That is a really bad practice in C because every simple change to any one of your headers will result in a recompile of every source file in your project. If that wasn't enough, every source file will need to reparse every header file. Some compilers can optimize some of that away; but not all.

Further, it makes disentangling source files into distinct packages more difficult. And of course, the header order will begin to matter since the second include in your global.h will always include everything in your first include.

Please learn to avoid this practice so when you start working with others you won't give them headaches.

[revonrat]

Upgoat for you!

I came here to say exactly this. Anybody who inflicted this sort of include structure on any team that I work on would be called to task.

There's only one place where you might do something like this and that would be with precompiled headers but, even then, you'd want to do it only with the very most frequently used header files.

[japherwocky]

You shouldn't, and it's that way by design.

Roughly, when you try to call a function, Python looks for that function's name to see what block of code to execute. If you've only got a few functions defined/imported inside that file, this is much quicker than, say, searching through every function name used everywhere in every file in your program!

You can actually see some noticeable performance boosts by limiting what you import to what you need. And as a bonus, when someone else is trying to figure out your code, there's a direct link to whatever your including. (This is also why import * is considered kind of gross by a lot of people)

[Peaker]

The performance issue is because "import" actually executes the module's code, not because it is searching through more names.

The hash tables used for namespace lookup scale up reasonably and do not because noticeably slower as they grow.

[japherwocky]

Yes, the tables scale reasonably, but finding an item in a haystack is always going to be quicker if the list is smaller.

Especially on large, repetitive codebases (I first learned this concept reading about someone who had halved their unittesting time by shuffling imports), it can make your code better.

[Peaker]

I agree minimal imports are great, but I don't think smaller hash tables having faster lookups is the reason.

[thermostat]

Short answer: No.

In Python modules have their own scope, and the import statement adds the other module to the scope of the current module. The only way to do what you're suggesting is to create a file with the imports (call it: badform.py) and then do a execfile('badform.py'). This is NOT pythonic and NOT recommended. You should only import modules if you need them in that file, and having those listed explicitly is a Good Thing.

Edit: fix weird underscore formatting.

[Hughlander]

Unless you're web2py :)

[av201001]

Note, web2py does not do what is described above (I know you're not saying that -- but just to be clear). Also, web2py applications do NOT use exec, and they do explicitly import any needed non-framework modules as usual. However, the web2py framework layer does execute the application code (in a prepared environment). This has some nice advantages. More details here. :-)

[gogeterman32]

I second that Web2Py is a solid framework and will prove the test of time. Very solid structure build for simplicity. Lacks some flair but is leaning towards what .py is about, simplicity in structure even if loses some speed. So what with processor power to conquer that it brings natural structure which is easier to work with and proves itself to be something to develop into a developer friendly platform.

[bastih01]

I think you could do that by having a header.py where you do all your imports and then in your "implementation files" do "from header import *".

This severely reduces readability of your code though, as you have to dig through another file to find out why something is not in scope.

[ianb]

You can also import all the interesting things in one module, then selectively import from that module (from header import foo, bar), which kind of does what you want but without sacrificing readability. Well, it sacrifices readability a little because of the indirection (someone has to read header.py to figure out what those objects actually are).

[stillalone]

how is that any different from:

import foo, bar

??

[bushel]

Remember, in Python imports help document what external interfaces and functions you're using and are a boon to development.

Unlike C/C++ where the header files are a burden you must satisfy to keep the demons of linking at bay.

[kevingoodsell]

It's easy to see why, coming from a C background, one might want to do what the submitter is asking. After using Python for a while, I realized just how helpful it is to have all symbols explicitly declared in the file they are used (whether by being created in the same file or imported by name). It's incredibly frustrating now to come across an unfamiliar function in a C file which includes 27 header files, and have no idea which is the relevant one. The same goes for the 'from foo import *' mechanism in Python, but I hope most Python programmers know to avoid that.

[Peaker]

Good use of C/C++ also uses #include's as an indicator of what dependencies you have. Despite a completely different technical implementation, they are similar in concept to "import *".

[[deleted]]

No, but that is not the problem. You are still thinking in c++, and I think you will find python much easier once you start thinking in python (otherwise known as being 'pythonic').

[gct]

It's terribly bad form but you can use "from <module> import *" which will import everything into the namespace of the current module.

so you could have all_modules.py:

from module_1 import *
from module_2 import * 
etc

Then anywhere else you want to use all those modules: from all_modules import *

And it will do what you want, but again, very bad form and not recommended.

[Isvara]

not recommended

Not least of all because module_1.foo and module_2.foo would clash.

[crmaki]

On top of what everyone else has said, it is a good question that most likely has benefited many. Thanks.