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
--
http://mail.python.org/mailman/listinfo/python-list
