C++ "include" behavior instead of "from" and "import"

include subcodefile
from subcodefile include ***#function or section?

I’m a beginner who has been programming in Python for 1 month
The main program file that has become too long If you try to separate files (modules) by approximate By role
It does not seem to be very suitable for such applications, and the “scope” is complicated. i confused
like below case. (those are 13years ago :0)
[Global Variable from a different file Python - Stack Overflow]
[make variable global to multiple files in python - Stack Overflow]

so i’am suggest this
command combines files. Just like C++ “include” is “as far as I know” such behavior
13years ago this stackoverflow question by someone.
so I’m sorry if a simple solution or way of doing things has been added to Python as it is now, I didn’t find it

how is this idea?

this post moved from here
[C++ include behavior instead of "from"and"import" · Issue #108706 · python/cpython · GitHub]

The lack of proper modules and scoping in C and C++ is widely recognized as a defect of these languages, not a nice feature. Virtually all modern languages have a module system, even C++ is gaining one. Python seems very unlikely to gain module-less global variables.


Thanks for your reply.
However, I even tried to restore the code that I had separated due to the unexpected wall of its strict control range :confused:
Although I thought that the code would be a bit verbose, but using “global” would be fine. But that didn’t solve it.
According to the linked answer, it is a problem such as the namespace of the module rather than the scope.
By preparing a declarative-only file and calling it once as a function… There must be a tricky workaround like that.
If you are told not to separate files, and if you do, make them well, yes.
Many people assume behavior like include and be as confused as they or the people at stackoverflow.:confused:

Therefore, I thought it would be good if there was a function that could import as a “file” apart from “from/import”.

You could try using exec(code, globals())

1 Like

Right now, I’m investigating “what kind of functions were presented” :thinking:
These pages for a detailed explanation of docs.python and in your own language
[【Python3】関数内でグローバル変数を動的定義 - Qiita]
It seems that there is a stronger ability than just being ‘global’.
For the time being, I’ll try to fix my program with this!thanks

PS.No, that’s the content here.

I recommend that you do not copy the approach of those questioners. The first didn’t understand modules (13 years ago). The second has created a situation where it is difficult to predict the result.

import can solve that problem when used well. I think @Rosuav is suggesting something advanced before we know what problem you’re solving.

In general, modifying the globals of another module is a bad idea. What you usually do is break the code up into functions that communicate with the main program by receiving arguments and returning values, not by referring to global variables outside their scope. (You might define classes too.)

Then it is possible to move the functions (and classes) to modules and import those modules into your main program file.

If that isn’t enough, try asking in Help “How do I use import to break this program up?” with a simple example similar to your real work.


Thank you for the clarity I feel that this is a method that can be used somehow.
I feel that my understanding of global has improved a little.

But this is a way of modularization, so I would like to continue to ask for a simple code file split.

That’s… exactly what import does, and does better than what C or C++ offers. Even if all the code were in the same file, you would still have to “receive arguments and return values”. That’s just… using functions normally.

If there’s a specific thing that you found difficult using import, please post in the Help section to ask clearly about how to fix the code. This is better than trying to convince everyone else that the feature should work differently (or in another way in addition to how it already works), when you already acknowledge that you don’t fully understand the feature.

1 Like

In C++ globals can accessed from any compilation unit.
You just need the extern declaration.

But in python there is no such thing.
global in python is for accessing a variable defined at module level.

If you split a function that depends on a global value into another file it will not work.
You need to refactor the code so that tne global is not needed.

One way is to put the global values into an instance of a class and pass that around.

Early in my career I was told that global variables are evil and to minimise their use.
And that was in a C type language, use a struct etc. I think that was good advice and I still follow it.


With the thought that this is what it meeaans (toned down towards the end)
I made it myself (half-made)
I don’t know if I’ll use it myself… I thought
[GitHub - Suletta-Majo/combpartpy: I plan to combine the main Python program written in an appropriate splitRequirements xxxxx.part0.py up to 99 forms]
If you’re like here, you can write it in a few minutes, but it took 24 hours (including how to use github)
This is a feature request topic, but in the sense of showing that there is also a direction to create your own

with open('myfile.py') as f: exec(f.read())

This code does the include you are requesting.

1 Like

How simple it is …
I suspect it’s too easy and read it one letter at a time. thanks😇

I did a quick look at the behavior of exec and I’m a beginner, so my observation may be wrong.
exec “executes” a given object as a sentence, so I thought it couldn’t handle multiple files like I had in mind.
Code parts for multiple fields that are “not modular or classified” (Normally essentially cramming everything into main.py)

if 5 file
TCP/IP “related”
Chat UI “Related”
Main Program 1
Main Program 2
Main Program 3
With exec, when you run main2, you can’t call function main3 (that’s what I imagined)

Yes, that’s correct. You would need to exec each file individually.

1 Like

While this works, it would be frowned upon by any code reviewer I know.


While I agree debugging the result of the one liner has its adventures and can be a bit opaque, its code that’s reliable and is consistent in its operation and function that I happen to utilize in my software.

The issue in my view isn’t being “opaque” (it’s pretty clear to me what’s going on, actually); it’s that this should not be done in any normal circumstance. The import system works the way it does for a reason, and OP has not demonstrated a compelling use case for anything else, aside from familiarity with an approach that almost everyone else agrees is inferior.

To each their own I guess, the include aforementioned works great for me, I find the opposite to be true, the generic import is inadequate. Years of programming experience have taught me, if it works, good, if it doesn’t, rewrite until it does, keep it savvy simple a mantra to get things done.

What concrete problem do you commonly encounter with ordinary import that is readily solved this way?

This approach will thwart linters and static type checkers and IDEs. It also defeats Python’s built-in module caching, so it will be less efficient. Since it subverts the (reasonable) assumption that modules live in sys.modules, may cause any other libraries in use to behave unpredictably. Of course, it will confuse any one else who ever needs to read the code, wasting other people’s time. Never mind “frown upon”, as a reviewer I would automatically fail this on sight.