<[EMAIL PROTECTED]> wrote: ... > and here is the test script, test1.py > ------------------------------------- > > from test2 import glbl, inc_glbl, get_glbl
Think of this as roughly equivalent to: import locl glbl = test2.glbl and so on. That is, after the 'from test2 import', the two names test1.glbl and test2.glbl refer to the same object. But if you now rebind name test2.glbl to refer to a distinct object, that of course has no effect on name test1.glbl. > I would expect the three values to be ( 25, 26, 26 ), but what I get is Why? Take an equivalent: a = 25 b = a a = 26 would you now expect name b to be magically rebound to 26? If so, then you have a very peculiar mental model for name/value correspondences, one that doesn't happen to hold in any language I know, surely not in Python. To repeat a commonly used metaphor: think of names as post-it notes that may be attached to some piece of furniture, and moved from one to another. The notes are NOT attached to each other, but rather to the objects: moving one post-it does not affect other post-its. > It seems that the references to 'glbl' are seeing a local copy, rather No copy whatsoever is involved. After the assignment (binding) you do with 'from test2 import', names test1.glbl and test2.glbl refer to the same object (value). If you now rebind either name, the other is unaffected. > than the original. This is not what the literature says should be > happening. If you can point to sentences in "the literature" which have misled you into believing a different behavior would be expected, I'll do my best to fix those sentences (as a book and article author, editor, reviewer, and Python contributor). While the Python docs, including books &c, are far from perfect, I doubt there is any such blooper left in them. > I am looking for a way to share data between modules. Can If you really must, consider using a container object. The most suitable container object for these tasks is often a module. I.e., code, in test1: import test2 and then refer to test2.glbl throughout. I.e., forget 'from', use 'import'. As I wrote in Python in a Nutshell, p. 120, last paragraph before "Module Loading": """ In general, the import statement is a better choice than the from statement. I suggest you think of the from statement [...] as [a] convenience meant only for occasional use in interactive Python sessions. If you always access module M with the statement import M, and always access M's attributes with explicit syntax M.A, your code will be slightly less concise, but far clearer and more readable. """ I don't know how I could have put this advice more strongly or more directly (I continue with explanations about the cases in which 'from' is instead appropriate, chiefly getting single modules from packages). Giving strong direct advice, rather than just reference info, in a book of the "in a Nutshell" series, is not common, but I do it quite a bit; after all, "how does Python work exactly", e.g. the fact that 'from X import Y' is almost the same as 'Y = X.Y', is pretty simple to explain, and so takes up little space -- OTOH, the consequences of this, such as "thus, generally, don't use 'from', use 'import'" may not be obvious to readers, so I point them out directly. Of course, that doesn't help much if people don't _read_ it;-). Alex -- http://mail.python.org/mailman/listinfo/python-list
