scope of function parameters (take two)

[Thomas Rachel]

Am 31.05.2011 02:28 schrieb Henry Olders:

> This suggests that the decision to make unassigned (ie "free"
> variables) have a global scope, was made somewhat arbitrarily to
> prevent clutter. But I don't believe that the feared clutter would
> materialize. My understanding is that when a variable is referenced,
> python first looks for it in the function's namespace, then the
> module's, and finally the built-ins. So why would it be necessary to
> declare references to built-ins as globals?

Not for the builtins, but for the global ones.

Suppose you have a module

def f(x):
    return 42

def g(x, y):
    return f(x) + f(y)

Would you really want to need a "global f" inside g?


Besides, this doesn't have to do with your original problem at all. Even 
then, a

def h(x):
    x.append(5)
    return x

would clobber the given object, because x is just a name for the same 
object which the caller has.

> What I would like is that the variables which are included in the
> function definition's parameter list, would be always treated as
> local to that function (and of course, accessible to nested
> functions)

They are - in terms of name binding. In Python, you always have objects 
which can be referred to from a variety of places under different names.

Maybe what you want are immutable objects (tuples) instead of mutable 
ones (lists)...


> I don't believe I'm the only person who thinks this way. Here is a
> quote from wikipedia: "It is considered good programming practice to
> make the scope of variables as narrow as feasible

Again: It is the way here.

Think of C: there you can have a

int f(int * x) {
     *x = 42;
     return x;
}

The scope of the variable x is local here. Same in Python.
The object referred to by *x is "somewhere else", by design. Same in Python.


> If making python behave this way is impossible, then I will just have
> to live with it.

Even if I still think that you are confusing "scope of a name binding" 
and "scope of an object", it is a conceptual thing.

Surely it would have been possible to do otherwise, but then it would be 
a different language. Objects can be mutable, period.

In MATLAB, e.g., you have what you desire here: you always have to pass 
your object around and get another ne back, even if you just add or 
remove a field of a struct or change the value of a field.

HTH,

Thomas