[me] > > But I don't think that changing the "from M import v" semantics so > > that local assignment to v changes the binding of M.v as well is > > defensible. > > I agree, however, I think that having: > > from M import v > > causing a name binding that is broken by local > assigment to v *is* defensible and reasonably > implementable. > > Changes to 'v' in M (including by reload of M) would be > reflected locally unless someone did: > > v=something > > locally. Local assignment would negate an import, as it > does now. Hm, but it still wouldn't have the same semantics as currently, and that's still a monster hiding under the bed until you're nearly asleep. Consider this example: # in M: verbose = 1 # in __main__: from M import verbose # somewhere else: M.verbose = 0 Under the current semantics, that would have no effect on verbose in __main__; but with your semantics it would. I think that is very hard to explain; even more so if you say that assigning a different value to __main__.verbose does not change M.verbose and furthermore breaks the connection. This means that if I add verbose = verbose to the __main__ code the semantics are different! I don't understand why you wanted these semantics in the first place. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4