private variables/methods
Sean Ross
sross at connectmail.carleton.ca
Mon Oct 13 17:01:05 EDT 2003
More information about the Python-list mailing list
Mon Oct 13 17:01:05 EDT 2003
- Previous message (by thread): private variables/methods
- Next message (by thread): private variables/methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"Harri Pesonen" <fuerte at sci.fi> wrote in message news:SMDib.231$8j.6 at reader1.news.jippii.net... > Christopher Koppler wrote: > > Hmmm, asking naively: why not make global (or some better name, I > > don't have any good ideas however) the self of the current module - > > i.e. instead of > > > > def fun(): > > global x > > x = somevalue > > > > or your import, you'd use > > > > def fun(): > > global.x = somevalue Christopher: Hi. You couldn't use "global" that way for backwards compatability reasons. Still, I like the overall idea. [snip] > Sounds good to me. So if you have now > > a = 1 > def b(): > a = 2 > > This would cause a compiler warning that a global "a" already exists. Harri: Hi. Actually, I don't think that is what's intended. Rather, if you want to use the global variable a, you will need to access it through the current module object, which can be referenced using global, i.e., a = 1 def b(): global.a = 2 # rebinds the global variable a a = 3 # binds a new local variable a, the global variable a is unaffected. print "a values: global = %s; local = %s"%(global.a, a) #output a values: global = 2; local = 3 the local and global variables a will not be confused, because the global variable a can only ever be referenced in the local scope via the current module reference ("global"). Meaning, if you want to use a global variable in a scope other than at the module level , you'll have to preface it with "global.". > So > the programmer should write either > > def b(): > global.a = 2 > > or > > def b(): > local.a = 2 > > The latter of course creates a new local variable with the same name. > After this it is OK to use just "a" without "local" prefix? > > def b(): > local.a = 2 > a = 3 > So, continuing from the explanation above, you will not have to say "local.a = 2" to bind a local variable. All variables will be local by default. Variables from other namespaces (such as globals) will have to be explicitly resolved (e.g. "global.a = 2") > How about the following: > > def b(): > global.a = 2 > a = 3 > > Is the second "a" still global? > No. > The idea with "Option Explicit" gets around this differently. The > following creates a new local variable: > > def b(): > var a = 2 > > While the following refers to the global variable, if there is no local > variable with the same name: > > def b(): > a = 2 > > This would be more beautiful. > Making a variable local by default, and requiring that globals be accessed explicitly seems like a better path to me. As far as I know, the use of globals is generally discouraged. So a lot of people try to avoid using them in code, when they can. But local variables occur all the time. Using "Option Explicit" would seem to be making you write more code for something that happens more often (local variable binding), and less code for something that is discouraged and should be happening less often (global variable rebinding). But maybe thats just me... Sean
- Previous message (by thread): private variables/methods
- Next message (by thread): private variables/methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list