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