Re: Variable scope inside and outside functions - global statement being overridden by assignation unless preceded by reference

On Sat, 9 Mar 2024 at 03:42, Grant Edwards via Python-list
<python-list@python.org> wrote:

>
On 2024-03-08, Chris Angelico via Python-list <python-list@python.org> wrote:

On Sat, 9 Mar 2024 at 00:51, Grant Edwards via Python-list
<python-list@python.org> wrote:
>

One might argue that "global" isn't a good choice for what to call the
scope in question, since it's not global. It's limited to that source
file. It doesn't make sense to me to call a binding "global", when
there can be multile different "global" bindings of the same name.

>
Most "globals" aren't global either, since you can have different
globals in different running applications.

>
To me, "global" has always been limited to within a single
process/address space, but that's probably just bias left over from
C/Pascal/FORTRAN/assembly/etc. It never occurred to me that a global
called "X" in one program on one computer would be the same as a
global called "X" in a different program on a different computer
somewhere else on the "globe".
>

Yeah. My point is, though, the name "global" is a bit of a hack
anyway, so it's not THAT big a deal if it has other caveats too. For
example, let's say you always "import globals" at the top of every
script, and then assign "globals.x = 123" etc. Now you have a concept
of globals that spans the entire application, right? Well, no, not if
you use multiprocessing.
So, go ahead and call them globals, but people will always have to
learn about exactly what that means.
ChrisA