Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6701

Re: scope of function parameters (take two)

Show all headers | View raw

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

Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: scope of function parameters (take two) Henry Olders <henry.olders@mcgill.ca> - 2011-05-30 20:28 -0400
  Re: scope of function parameters (take two) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-31 04:35 +0000
  Re: scope of function parameters (take two) Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-05-31 07:03 +0200

csiph-web