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
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
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.
Therefore, I thought it would be good if there was a function that could import as a “file” apart from “from/import”.
Right now, I’m investigating “what kind of functions were presented”
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
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.
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.
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.
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)
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.
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.
