private variables/methods

[Harri Pesonen]

Christopher Koppler wrote:
> On Sun, 12 Oct 2003 22:42:12 GMT, Alex Martelli <aleaxit at yahoo.com>
> wrote:
> 
>>Sean Ross wrote:
>>
>>>Hi.
>>>I'm not sure I'm clear on what behaviour "import __current_module__" is
>>>expected to have.
>>
>>Just like any other import, it binds the name to a module object -- except
>>that it specifically binds said name to the module containing the function 
>>that executes this import statement.  The use case is: deprecating the
>>global statement.  Setting a global variable would instead use:
>>   import __current_module__
>>   __current_module__.thevariable = 23
> 
> 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
> 
> And every module would set it's __global__ to itself by default...
> 
> Just a naive idea, of course...

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. 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

How about the following:

def b():
	global.a = 2
	a = 3

Is the second "a" still global?

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.

Harri