Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Mon, 19 Aug 2013 19:40:49 +0200
From: Antoon Pardon <antoon.pardon@rece.vub.ac.be>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130704 Icedove/17.0.7
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Importing variables non-deterministic?
References: <a75383ec-b363-4ad4-9703-ca5d8ea614df@googlegroups.com> <520f9054$0$30000$c3e8da3$5496439d@news.astraweb.com> <5211C5BD.5040209@rece.vub.ac.be> <kusidq$kaa$1@ger.gmane.org> <mailman.16.1376900198.19984.python-list@python.org> <52124e81$0$29986$c3e8da3$5496439d@news.astraweb.com>
In-Reply-To: <52124e81$0$29986$c3e8da3$5496439d@news.astraweb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.38.1376934119.19984.python-list@python.org>
Lines: 91
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:52702

Op 19-08-13 18:57, Steven D'Aprano schreef:
> On Mon, 19 Aug 2013 10:16:36 +0200, Antoon Pardon wrote:
>
>> Op 19-08-13 09:45, Dave Angel schreef:
>>> Antoon Pardon wrote:
>>>
>>>> Op 17-08-13 17:01, Steven D'Aprano schreef:
>>>>>
>>>>> And here you re-import the name "y" from struct_global. That rebinds
>>>>> the current module's "y" with whatever value struct_global.y has
>>>>> *now*, rather than a second (or a minute, or an hour) earlier when
>>>>> the first import took place. Obviously at some point between the
>>>>> first import and the second import, struct_global.y must have been
>>>>> reassigned from -1 to 62.
>>>>>
>>>>> This goes to show why global variables are considered harmful, and
>>>>> why clean, modern program design tries to reduce the use of them as
>>>>> much as possible. Global variables are too easily modified by, well,
>>>>> *anything*. The sort of behaviour you are seeing is sometimes called
>>>>> "action at a distance" -- something, anything, anywhere in your
>>>>> program, possibly buried deep, deep down inside some function you
>>>>> might never suspect, is changing the global variable.
>>>>
>>>> I think you are overstating your case. Classes and functions are
>>>> variables too and in general nobody seems to have a problem with them
>>>> being global.
>>>>
>>>>
>>> It's global *variables* that are to be avoided.  constants like clsases
>>> and functions are fine.  On the other hand, class attributes can be
>>> variable, and thus are to be avoided when reasonable.
>>
>> Python has no constants. Classes and functions can be changed just like
>> any other variable. I agree that classes and function are generally
>> meant to be constant, but often enought so are global int variables.
>
> You are technically correct, but missing the point. If I wrote code that
> went around reassigning names from one function to another function, I
> would very likely soon work myself into a state of utter confusion:
>
> def func(x):
>      ...
>
> # later
> save_func = func
> func = lambda x, y: do_stuff(x, 3*y)-4
> result = something_that_calls_func()
> func = save_func
>
>
> Nasty, horrible code, yes? But it's nasty and horrible because "func" is
> bound to a function, it would be equally nasty and horrible if it was a
> data type (a string, a list, an int, a flag, ...) instead.
>
> Since classes and functions are First Class objects in Python, naturally
> if you treat them as global *variables* rather than global *constants*
> you can end up with problems. The problem is not the global part alone.
> Global constants, or pseudo-constant-by-convention-only, are fine.

I don't think there is a big disagreement on this, I just thought
you overstated your case as you originally worded it.

>> And some of those that do change, only do so in the initialisation phase
>> and should be considered constant for the rest of the program.
>>
>> My point was that Steven has no way of knowing what exactly is going on
>> here and so shouldn't be making such a sweeping statement.
>
> On the contrary, I can read the Original Poster's description of the
> problem, and then use my ability to reason to deduce what the most likely
> explanation was.
>
> Now of course I might be wrong. I don't claim infallibility or
> omniscience. But I'm not an idiot, and if the OP says that a global
> variable has one value at one time, and then some time later has a
> different value, there are two likely possibilities:
>
> * The variable was changed by some other piece of code, i.e. it
>    actually was being used as a *global variable*.

Sure. But was that because it was intended to be used as a variable
or was the intention to use it as a constant but because of a bug
it was changed anyway? I don't think you have enough information
to discriminate between these two cases and for the possibility
of this being the latter case I found your disgression into the
harm of global variable too strongly worded.

-- 
Antoon Pardon.