Importing variables non-deterministic?

[Antoon Pardon]

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.