Mailing List Archive

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.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

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".


--
https://mail.python.org/mailman/listinfo/python-list

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
--
https://mail.python.org/mailman/listinfo/python-list