Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <F4EAD1ED-563D-4D6E-A50C-68308A9F26B7@mcgill.ca>
References: <F8395F78-615E-4FBD-B6FC-1D6173EAEA45@mcgill.ca> <F4EAD1ED-563D-4D6E-A50C-68308A9F26B7@mcgill.ca>
Date: Mon, 30 May 2011 17:52:27 -0700
Subject: Re: scope of function parameters (take two)
From: Benjamin Kaplan <benjamin.kaplan@case.edu>
To: python-list@python.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2281.1306803220.9059.python-list@python.org>
Lines: 154
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:6684

On Mon, May 30, 2011 at 5:28 PM, Henry Olders <henry.olders@mcgill.ca> wrot=
e:
>
> On 2011-05-29, at 4:30 , Henry Olders wrote:
>
>> I just spent a considerable amount of time and effort debugging a progra=
m. The made-up code snippet below illustrates the problem I encountered:
>>
>> def main():
>> =A0 =A0 =A0 a =3D ['a list','with','three elements']
>> =A0 =A0 =A0 print a
>> =A0 =A0 =A0 print fnc1(a)
>> =A0 =A0 =A0 print a
>>
>> def fnc1(b):
>> =A0 =A0 =A0 return fnc2(b)
>>
>> def fnc2(c):
>> =A0 =A0 =A0 c[1] =3D 'having'
>> =A0 =A0 =A0 return c
>>
>> This is the output:
>> ['a list', 'with', 'three elements']
>> ['a list', 'having', 'three elements']
>> ['a list', 'having', 'three elements']
>>
>> I had expected the third print statement to give the same output as the =
first, but variable a had been changed by changing variable c in fnc2.
>>
>> It seems that in Python, a variable inside a function is global unless i=
t's assigned. This rule has apparently been adopted in order to reduce clut=
ter by not having to have global declarations all over the place.
>>
>> I would have thought that a function parameter would automatically be co=
nsidered local to the function. It doesn't make sense to me to pass a globa=
l to a function as a parameter.
>>
>> One workaround is to call a function with a copy of the list, eg in fnc1=
 I would have the statement "return fnc2(b[:]". But this seems ugly.
>>
>> Are there others who feel as I do that a function parameter should alway=
s be local to the function? Or am I missing something here?
>>
>
> My thanks to all the people who responded - I've learned a lot. Sadly, I =
feel that the main issue that I was trying to address, has not been dealt w=
ith. Perhaps I didn't explain myself properly; if so, my apologies.
>
> I am trying to write python programs in a more-or-less functional program=
ming mode, ie functions without side effects (except for print statements, =
which are very helpful for debugging). This is easiest when all variables d=
eclared in functions are local in scope (it would also be nice if variables=
 assigned within certain constructs such as for loops and list comprehensio=
ns were local to that construct, but I can live without =A0it).
>
> It appears, from my reading of the python documentation, that a deliberat=
e decision was made to have variables that are referenced but not assigned =
in a function, have a global scope. I quote from the python FAQs: "In Pytho=
n, variables that are only referenced inside a function are implicitly glob=
al. If a variable is assigned a new value anywhere within the function=92s =
body, it=92s assumed to be a local. If a variable is ever assigned a new va=
lue inside the function, the variable is implicitly local, and you need to =
explicitly declare it as =91global=92.
> Though a bit surprising at first, a moment=92s consideration explains thi=
s. On one hand, requiring global for assigned variables provides a bar agai=
nst unintended side-effects. On the other hand, if global was required for =
all global references, you=92d be using global all the time. You=92d have t=
o declare as global every reference to a built-in function or to a componen=
t of an imported module. This clutter would defeat the usefulness of the gl=
obal declaration for identifying side-effects." (http://docs.python.org/faq=
/programming.html)
>
> This suggests that the decision to make unassigned (ie "free" variables) =
have a global scope, was made somewhat arbitrarily to =A0prevent clutter. B=
ut I don't believe that the feared clutter would materialize. My understand=
ing 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?
>
> What I would like is that the variables which are included in the functio=
n definition's parameter list, would be always treated as local to that fun=
ction (and of course, accessible to nested functions) but NOT global unless=
 explicitly defined as global. This would prevent the sort of problems that=
 I encountered as described in my original post. I may be wrong here, but i=
t seems that the interpreter/compiler should be able to deal with this, whe=
ther the parameter passing is by value, by reference, by object reference, =
or something else. If variables are not assigned (or bound) at compile time=
, but are included in the parameter list, then the binding can be made at r=
untime.
> And I am NOT talking about variables that are only referenced in the body=
 of a function definition; I am talking about parameters (or arguments) in =
the function's parameter list. As I stated before, there is no need to incl=
ude a global variable in a parameter list, and if you want to have an effec=
t outside of the function, that's what the return statement is for.
>
> 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 sco=
pe of variables as narrow as feasible so that different parts of a program =
do not accidentally interact with each other by modifying each other's vari=
ables. Doing so also prevents action at a distance. Common techniques for d=
oing so are to have different sections of a program use different namespace=
s, or to make individual variables "private" through either dynamic variabl=
e scoping or lexical variable scoping." (http://en.wikipedia.org/wiki/Varia=
ble_(programming)#Scope_and_extent).
>
> It also seems that other languages suitable for functional programming ta=
ke the approach I think python should use. Here is another quote from the w=
ikipedia entry for Common Lisp: "the use of lexical scope isolates program =
modules from unwanted interactions. Due to their restricted visibility, lex=
ical variables are private. If one module A binds a lexical variable X, and=
 calls another module B, references to X in B will not accidentally resolve=
 to the X bound in A. B simply has no access to X. For situations in which =
disciplined interactions through a variable are desirable, Common Lisp prov=
ides special variables. Special variables allow for a module A to set up a =
binding for a variable X which is visible to another module B, called from =
A. Being able to do this is an advantage, and being able to prevent it from=
 happening is also an advantage; consequently, Common Lisp supports both le=
xical and dynamic scope. (http://en.wikipedia.org/wiki/Common_Lisp#Determin=
ers_of_scope).
>
>
> If making python behave this way is impossible, then I will just have to =
live with it. But if it's a question of "we've always done it this way", or=
, " why change? I'm not bothered by it", then I will repeat my original que=
stion: Are there others who feel as I do that a function parameter should a=
lways be local to the function?
>
> And again, thank you all for taking the time to respond.
>
> Henry


Python doesn't have true globals. When we say "global" what we mean is
"module or built-in". Also, consider this code

from math import sin
def redundant_sin(x) :
    return sin(x)

In Python, everything is an object. That includes functions.  By your
definition, that function would either have to be written as
def redundant_sin(sin, x) :
and you would have to pass the function in every time you wanted to
call it or have a "global sin" declaration in your function. And you
would need to do that for every single function that you call in your
function body.





> --
> http://mail.python.org/mailman/listinfo/python-list
>