By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,818 Members | 1,313 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,818 IT Pros & Developers. It's quick & easy.

strings in the global section

P: n/a
I write a script:
#!/usr/bin/python
astring = "This is a String"

def fun1():
astring = "I modify it in fun1"
def fun2():
astring = "I modify it in fun2"
def main():
print astring
fun1()
print astring
fun2()
print astring
if __name__ == '__main__':
main()
~
~
And I am expecting the output to be:
This is a String
I modify it in fun1
I modify it in fun2

But it is not so. It always prints This is a String. astring declared
outside all the functions, is not in global section and values be
overwritten by functions accessing it?

- How is this working?
- What should I do to overwrite the string variable in the global
section within functions?

Thanks,
Senthil

Oct 12 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Phoe6 wrote:
But it is not so. It always prints This is a String. astring
declared outside all the functions, is not in global section and
values be overwritten by functions accessing it?

- How is this working?
If you assign "astring" inside the function body, it's a local name.
- What should I do to overwrite the string variable in the global
section within functions?
Put a "global astring" in the function to access the global name
instead.

BTW, think about using a better interface than globals.

Regards,
Björn

--
BOFH excuse #23:

improperly oriented keyboard

Oct 12 '06 #2

P: n/a
Bjoern Schliessmann wrote:
If you assign "astring" inside the function body, it's a local name.
- What should I do to overwrite the string variable in the global
section within functions?

Put a "global astring" in the function to access the global name
instead.
#!/usr/bin/python
global astring
astring = "This is a String"

def fun1():
global astring
astring = "I modify it in fun1"
def fun2():
global astring
astring = "I modify it in fun2"
def main():
print astring
fun1()
print astring
fun2()
print astring
if __name__ == '__main__':
main()
~
~
Works, but something different ?

Oct 12 '06 #3

P: n/a
Phoe6 wrote:
I write a script:
#!/usr/bin/python
astring = "This is a String"

def fun1():
astring = "I modify it in fun1"
def fun2():
astring = "I modify it in fun2"
def main():
print astring
fun1()
print astring
fun2()
print astring
if __name__ == '__main__':
main()

And I am expecting the output to be:
This is a String
I modify it in fun1
I modify it in fun2

But it is not so. It always prints This is a String. astring declared
outside all the functions, is not in global section and values be
overwritten by functions accessing it?

- How is this working?
- What should I do to overwrite the string variable in the global
section within functions?
http://docs.python.org/ref/global.html

def fun2():
global astring
astring = 'hey, I've changed!'

-tkc

Oct 12 '06 #4

P: n/a
Phoe6 wrote:
#!/usr/bin/python
global astring
astring = "This is a String"
A global declaration just says "look for this name in the module
namespace". Since you /are/ in the module namespace here, there's
no need to put "global" here.
Works, but something different ?
Excuse me, what do you mean?

Regards,
Björn

--
BOFH excuse #410:

Electrical conduits in machine room are melting.

Oct 12 '06 #5

P: n/a
>Works, but something different ?
>
Excuse me, what do you mean?
Sounded like the OP wanted a behavior similar to "auto-globals"
that has been a long-cursed aspect of PHP. That, without
specifying it, local-variables should be global if their name
exists in the global namespace. Python seems to behave this way
when reading, but when writing, writes to the local namespace.
Moderately confusing when first encountered, but it makes sense
in short order.

If auto-writing to globals were permitted, all sorts of weird
behaviors could ensue and accompanying breakage of existing code.
I'm quite happy with not using "global" at all (okay, there's
been once or twice I've wanted to modify a module-level settings
structure, but otherwise...).

For the most part, using "global" is cause to be smacked in the
head as it makes for a nightmare maint.-wise.

-tkc

Oct 12 '06 #6

P: n/a
Tim Chase wrote:
Sounded like the OP wanted a behavior similar to "auto-globals"
that has been a long-cursed aspect of PHP. That, without
specifying it, local-variables should be global if their name
exists in the global namespace.
Sounds like a source of many hard to track down bugs.
I'm quite happy with not using "global" at all (okay, there's
been once or twice I've wanted to modify a module-level settings
structure, but otherwise...).
AOL
For the most part, using "global" is cause to be smacked in the
head as it makes for a nightmare maint.-wise.
ACK.

Regards,
Björn

--
BOFH excuse #415:

Maintenance window broken

Oct 12 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.