from xx import yy

[Rick Johnson]

On Monday, November 13, 2017 at 10:59:06 AM UTC-6, bvdp wrote:

> Thanks all for confirming that I was wrong to use "from ..
> import".

In this case, but i wouldn't extrapolate that advice to mean
that the form `from X import Y` is _always_ bad. You just
need to understand the consequences of each unique form of
Python's import.

> Hmmm, perhaps for functions it might be okay. But,
> in most cases it's a lot more obvious to use
> module.function() when calling.
Well, again, i think you're over generalizing.

If the imported symbol is a "self-contained code object"
(aka: a function or a custom class, whether instanced or
not), or especially a "read-only variable", then `from mod
import x, y, z` won't typically cause any of these
surprises.

But of course, the previous paragraph only applies if i
understood your initial question "correctly". Meaning, in
the context of "your own personal expectations". My
understanding of those _expectations_ (aka: _your_
expectations), is that you assumed that by importing a
symbol (namely: `myvar`) into a "foreign module" (namely:
"test2.py") that such action would allow you to mutate the
_value_ of `myvar` from two distinct modules. But this is
not true. Because each module creates its own local
variables when names are imported. And that peculiarity is
directly related to Python's strange implementation of
global variables

(psst: which, in the next paragraph, you'll discover are not
really global at all!)

(but for now, let's keep that dirty little secret between
you and me, mmmkay?)

One important lesson to learn about Python is that it has no
"normally accepted" concept of "global variables". (meaning,
variables that are known to all scopes within a program). So
throw out everything you've ever know about global
variables.

Go ahead... We're waiting!

Sure, you can create a _real_ global variable in Python if
you were so inclined, but there is no "official support" for
doing such a thing, and it requires some esoteric knowledge
about how names are injected into module namespace by Python
itself. But, to unlock this knowledge, you'll first to
master the secret handshake and speakeasy a secret password.

"Officially" speaking, the most promiscuous naturally
occuring variable in a python program is what i call a
"Module Level Variable" (or MLV for short). MLVs are the
variables that are defined _outside_ of self-contained code
objects like functions and/or classes, and these are the
types of variables that require the use of the specialized
`global` keyword (at least, if one wishes to modify them
from inside a self-contained code object that is.)

So basically, what you were trying to do was to create a
global variable, a _real_ global variable that is, not the
fake and utterly confusing ones that Python implements,
nope, but a _real_, bonafide global variable that could be
mutated from inside multiple modules (or more generically,
multiple namespaces or scopes).

And i'm sorry, but you're not allowed to do that.

> Maybe a bit slower, but I'm sure it's negligible in most
> cases.  And, yes, I am trying to share state info between
> modules. Is this a bad thing? I guess I would write
> getter() and setter() functions for all this. But that does
> seem to remind me too much of some other language :)

I never write getters or setters unless i need functional
behavior during the reading or writing of an attribute. IOW,
if your getters and setters look like this:

    # pseudo
    some_value = "foo"

    def get_value():
        return some_value

    def set_value(new):
        some_value = value

...then you're wasting your time and that of those who are
forced to read the code. OTOH. If your getters and setters
can justify their existence like this:

    # pseudo
    some_value = "foo"

    def get_value():
        perform_some_test_or_action()
        return some_value

    def set_value(new):
        perform_some_test_or_action()
        some_value = new

Then it makes sense to use them. Sometimes the value needs
to be calculated; or updated; or type checked; or whatever.