Chris Angelico writes:
> When you import something, all you're doing is getting a local
> reference to it; "from foo import make_adder" is basically like saying
> "import foo; make_adder = foo.make_adder". The function itself is
> still the same, and it still remembers its original context.
Than
On Thu, Jan 13, 2022 at 9:43 PM Anssi Saari wrote:
>
>
> I ran into what seems odd scoping to me when playing with some matching
> examples for 3.10.
>
> I kinda thought that if I do from foo import * and from bar import * in
> the Python REPL, I'd get everything from foo and bar in the main
> sco
lokeshkopp...@gmail.com wrote:
>
>ok Peter Otten,
>but how to make a Class global??
Your class IS global. I still don't think you understand what you did
wrong. You've tripped into a strange little quirk of scoping. Here is
your code with some unimportant lines removes.
class Node:
def __i
On Thu, May 23, 2013 at 8:25 PM, wrote:
> ok Peter Otten,
> but how to make a Class global??
He gave some examples. It'd be helpful to quote some of his post, for
context... and preferably, show some proof that you've understood it.
You're starting a number of threads that look like you're tryi
ok Peter Otten,
but how to make a Class global??
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, May 23, 2013 at 8:23 PM, wrote:
> Thanks Chris Angelico,
> i am new to python can you suggest me how to remove the error and solve it.
> so,how can i create an instance for "Node" in that function??,is, it not
> possible to create an instance in such a way?
The problem isn't the instan
Thanks Chris Angelico,
i am new to python can you suggest me how to remove the error and solve it.
so,how can i create an instance for "Node" in that function??,is, it not
possible to create an instance in such a way?
--
http://mail.python.org/mailman/listinfo/python-list
lokeshkopp...@gmail.com wrote:
> i had written the following code i am unable to create the instance of the
> class "Node" in the method "number_to_LinkedList" can any one help me how
> to do ?? and what is the error??
>
>
> class Node:
> def __init__(self, value=None):
> self.valu
On Thu, May 23, 2013 at 7:51 PM, wrote:
> i had written the following code i am unable to create the instance of the
> class "Node" in the method "number_to_LinkedList" can any one help me how to
> do ??
> and what is the error??
It would really help if you post the actual exception and traceb
gusa...@gmail.com writes:
> What is the appropriate definition for the following behavior in
> Python 2.7 (see code below).
>
> Both functions have assignment in it (like "x = ") so I assume, that
> x is a local variable in both functions.
It's a local variable in both functions because it's a fo
Hi,
On Tue, Dec 04, 2012 at 02:55:44PM +0400, gusa...@gmail.com wrote:
> What is the appropriate definition for the following behavior in Python 2.7
> (see code below).
It has something to do with mutability of lists and that Python passes
around references and not the actual objects.
>
> def f
On Tue, 04 Dec 2012 14:55:44 +0400, gusarer wrote:
> What is the appropriate definition for the following behavior in Python
> 2.7 (see code below).
> Both functions have assignment in it (like "x = ") so I assume, that x
> is a local variable in both functions.
Well, yes, but that's not why x is
Steven D'Aprano wrote:
On Mon, 05 Dec 2011 19:57:15 +0100, Jean-Michel Pichavant wrote:
The proper way to propagate information with exceptions is using the
exception itself:
try:
songs = [Song(_id) for _id in song_ids]
except Song.DoesNotExist, exc:
print exc
I'm not entire
On Tuesday, December 6, 2011 2:42:35 PM UTC+8, Rainer Grimm wrote:
> Hello,
>
> > try:
> > songs = [Song(id) for id in song_ids]
> > except Song.DoesNotExist:
> > print "unknown song id (%d)" % id
> that's is a bad programming style. So it will be forbidden with python 3. T
Hello,
> try:
> songs = [Song(id) for id in song_ids]
> except Song.DoesNotExist:
> print "unknown song id (%d)" % id
that's is a bad programming style. So it will be forbidden with python 3. The
reason is that list comprehension is a construct from the functional world.
On Tue, Dec 6, 2011 at 9:57 AM, Roy Smith wrote:
> I may be in the minority here, but it doesn't bother me much that my use of
> 'id' shadows a built-in. Especially in small scopes like this, I use
> whatever variable names make the the code easiest to read and don't worry
> about shadowing bu
On 12/5/2011 5:36 PM, Roy Smith wrote:
Well, in my defense, I did ask a pretty narrow question, "Is id
guaranteed to be in scope in the print statement?".
Yes for 2.x, guaranteed no for 3.x.
If you had simply asked "Is the loop variable of a list comprehension
guaranteed to be in scope after
Sigh. I attempted to reduce this to a minimal example to focus the discussion
on the question of list comprehension variable scope. Instead I seem to have
gotten people off on other tangents. I suppose I should post more of the real
code...
song_ids = request.POST.getlist('song_id')
On Mon, 05 Dec 2011 19:57:15 +0100, Jean-Michel Pichavant wrote:
> The proper way to propagate information with exceptions is using the
> exception itself:
>
> try:
> songs = [Song(_id) for _id in song_ids]
> except Song.DoesNotExist, exc:
> print exc
I'm not entirely sure that this is
Well, in my defense, I did ask a pretty narrow question, "Is id guaranteed to
be in scope in the print statement?". While I will admit that not knowing
whether I could alter the exception, or whether id masked a builtin or not does
complexify answering some questions, those are questions I didn
On 12/5/2011 2:15 PM, Roy Smith wrote:
Hmmm, the use of id was just a simplification for the sake of
posting. The real code is a bit more complicated and used a
different variable name, but that's a good point.
As far as storing the value in the exception, unfortunately,
DoesNotExist is not my
Hmmm, the use of id was just a simplification for the sake of posting. The
real code is a bit more complicated and used a different variable name, but
that's a good point.
As far as storing the value in the exception, unfortunately, DoesNotExist is
not my exception; it comes from deep within d
Roy Smith wrote:
Consider the following django snippet. Song(id) raises DoesNotExist if the id
is unknown.
try:
songs = [Song(id) for id in song_ids]
except Song.DoesNotExist:
print "unknown song id (%d)" % id
Is id guaranteed to be in scope in the print statement? I
Roy Smith wrote:
> Consider the following django snippet. Song(id) raises DoesNotExist if
> the id is unknown.
>
> try:
> songs = [Song(id) for id in song_ids]
> except Song.DoesNotExist:
> print "unknown song id (%d)" % id
>
> Is id guaranteed to be in scope in the prin
Roy Smith writes:
> Consider the following django snippet. Song(id) raises DoesNotExist
> if the id is unknown.
>
> try:
> songs = [Song(id) for id in song_ids]
> except Song.DoesNotExist:
> print "unknown song id (%d)" % id
>
> Is id guaranteed to be in scope in the pri
On Mon, Dec 5, 2011 at 9:04 AM, Roy Smith wrote:
> Consider the following django snippet. Song(id) raises DoesNotExist if
> the id is unknown.
>
>try:
>songs = [Song(id) for id in song_ids]
>except Song.DoesNotExist:
>print "unknown song id (%d)" % id
>
> Is id guaranteed
On Tue, May 31, 2011 at 6:04 PM, Daniel Kluev wrote:
> On Wed, Jun 1, 2011 at 3:16 AM, Ian Kelly wrote:
>>
>> There is no "decorator" module in the standard library. This must be
>> some third-party module. The usual way to do this would be:
>
> Yes, but its very useful for decorators and provi
On Wed, Jun 1, 2011 at 3:16 AM, Ian Kelly wrote:
>
> There is no "decorator" module in the standard library. This must be
> some third-party module. The usual way to do this would be:
Yes, but its very useful for decorators and provides some
not-readily-available functionality.
http://pypi.pyth
I was thinking you could do something strange like:
kw = {object(): None}
def test(**kw):
print kw
test(**kw)
however, upon testing it (in Python 2.6), I found that it errors while
trying to unpack the kw dict stating that they must all be strings.
Perhaps making a custom class derived off ba
Henry Olders wrote:
Clearly, making a copy within the function eliminates the possibility of
the side effects caused by passing in mutable objects. Would having the
compiler/interpreter do this automatically make python so much
different?
It would be a different language.
~Ethan~
--
http://m
Henry Olders wrote:
[...] what I want is a function that is free of side effects [...]
Shoot, that's easy! Just write your function to not have any!
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
On May 31, 9:46 pm, rusi wrote:
> So you then use (something like)
>
> fnc2(c): return c[0:1] + c[2:]
Er sorry -- that should have been
def fnc2(c): return c[0:1] + ('having',) + c[2:]
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, May 31, 2011 at 10:34 AM, Chris Kaynor wrote:
> Is there any reason not to simplify this to:
> def copy_args(f):
> @functools.wraps(f)
> def wrapper(*args, **kw):
> nargs = copy.deepcopy(args)
> nkw = copy.deepcopy(kw)
> return f(*nargs, **nkw)
> return wrappe
On May 29, 1:30 pm, Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a program.
> The made-up code snippet below illustrates the problem I encountered:
>
> def main():
> a = ['a list','with','three elements']
> print a
> print fnc1(a)
>
On Tue, May 31, 2011 at 9:16 AM, Ian Kelly wrote:
> On Tue, May 31, 2011 at 1:38 AM, Daniel Kluev wrote:
> > @decorator.decorator
> > def copy_args(f, *args, **kw):
> >nargs = []
> >for arg in args:
> >nargs.append(copy.deepcopy(arg))
> >nkw = {}
> >for k,v in kw.iteritem
On Tue, May 31, 2011 at 1:38 AM, Daniel Kluev wrote:
> @decorator.decorator
> def copy_args(f, *args, **kw):
> nargs = []
> for arg in args:
> nargs.append(copy.deepcopy(arg))
> nkw = {}
> for k,v in kw.iteritems():
> nkw[k] = copy.deepcopy(v)
> return f(*nargs, **nkw)
On 5/31/2011 3:17 AM, Henry Olders wrote:
Clearly, making a copy within the function eliminates the possibility of
the side effects caused by passing in mutable objects.
Mutable objects and mutating methods and functions are a *feature* of
Python. If you do not like them, do not use them.
>
On 5/31/2011 2:37 AM, Henry Olders wrote:
what I want is a function that is free of side effects back through
the parameters passed in the function call.
You can get that by refraining from mutating parameter objects.
Simple as that.
Just do not expect Python to enforce that discipline on ever
On Dienstag 31 Mai 2011, Henry Olders wrote:
> You're partially right - what I want is a function that is
> free of side effects back through the parameters passed in
> the function call.
I don't know any object oriented language where it is not
possible to change objects passed in as parameters.
On Tue, May 31, 2011 at 5:17 PM, Henry Olders wrote:
> Clearly, making a copy within the function eliminates the possibility of the
> side effects caused by passing in mutable objects. Would having the
> compiler/interpreter do this automatically make python so much different?
Yes, it would make
On Tue, May 31, 2011 at 6:17 PM, Henry Olders wrote:
> Clearly, making a copy within the function eliminates the possibility of the
> side effects caused by passing in mutable objects. Would having the
> compiler/interpreter do this automatically make python so much different?
As I've pointed, yo
On 2011-05-31, at 24:35 , Dan Stromberg wrote:
>
> On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote:
>
> Be careful not to conflate global scoping or global lifetime, with mutability
> or pure, side-effect-free functions (callables). It sounds like what you
> want is immutability and/or
On 2011-05-30, at 20:52 , Benjamin Kaplan wrote:
> On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote:
>>
>> On 2011-05-29, at 4:30 , Henry Olders wrote:
>>
>
> Python doesn't have true globals. When we say "global" what we mean is
> "module or built-in". Also, consider this code
>
> from ma
On Mon, May 30, 2011 at 11:37 PM, Henry Olders wrote:
> On 2011-05-31, at 1:13 , Wolfgang Rohdewald wrote:
>>
>> what you really seem to want is that a function by default
>> cannot have any side effects (you have a side effect if a
>> function changes things outside of its local scope). But
>> th
On 2011-05-31, at 1:13 , Wolfgang Rohdewald wrote:
>
> what you really seem to want is that a function by default
> cannot have any side effects (you have a side effect if a
> function changes things outside of its local scope). But
> that would be a very different language than python
You're pa
On Tue, May 31, 2011 at 4:13 PM, Wolfgang Rohdewald
wrote:
> what you really seem to want is that a function by default
> cannot have any side effects (you have a side effect if a
> function changes things outside of its local scope). But
> that would be a very different language than python
This
Daniel Kluev writes:
> On a sidenote, I wonder what is the reason to keep word 'variable' in
> python documentation at all. I believe word 'name' represents concept
> better, and those, who come from other languages, would be less likely
> to associate wrong definitions with it.
I agree, but the
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 ref
On Dienstag 31 Mai 2011, Henry Olders wrote:
> 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) but NOT global unless explicitly defined
> a
On Mon, 30 May 2011 20:28:34 -0400, Henry Olders wrote:
> I am trying to write python programs in a more-or-less functional
> programming mode, ie functions without side effects (except for print
> statements, which are very helpful for debugging). This is easiest when
> all variables declared in
On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote:
> 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) but NOT global
> unless explicitly de
On Tue, May 31, 2011 at 1:18 PM, Daniel Kluev wrote:
> On Tue, May 31, 2011 at 2:05 PM, Chris Angelico wrote:
>> Infinitely-nested scoping is simply one of the casualties of a
>> non-declarative language.
>
> Well, this is not accurate, as you can have 'infinitely-nested
> scoping' in python, in
On Tue, May 31, 2011 at 2:05 PM, Chris Angelico wrote:
> Infinitely-nested scoping is simply one of the casualties of a
> non-declarative language.
Well, this is not accurate, as you can have 'infinitely-nested
scoping' in python, in form of nested functions. For example, you can
use map(lambda x
On Tue, May 31, 2011 at 10:28 AM, Henry Olders wrote:
> 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 so that different parts of a program do not
> acc
On Tue, May 31, 2011 at 12:30 PM, Terry Reedy wrote:
> Again, go back and reread what I and other wrote. I believe that you are, in
> part, hypnotized by the work 'variable'. Can you define the word? There are
> 10 to 20 possible variations, and yours is probably wrong for Python.
On a sidenote,
On 5/30/2011 8:28 PM, Henry Olders wrote:
Sadly, I feel that the main issue that I was trying to address, has
not been dealt with.
False. Please go back and read what I and others wrote before.
...
What I would like is that the variables which are included in the
function definition's param
On Tue, May 31, 2011 at 11:28 AM, Henry Olders wrote:
> 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
You still mis-reading docs and explanations you received from the list.
Let me try a
On Mon, May 30, 2011 at 5:28 PM, Henry Olders wrote:
>
> On 2011-05-29, at 4:30 , Henry Olders wrote:
>
>> I just spent a considerable amount of time and effort debugging a program.
>> The made-up code snippet below illustrates the problem I encountered:
>>
>> def main():
>> a = ['a list','
On 2011-05-29, at 4:30 , Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a program.
> The made-up code snippet below illustrates the problem I encountered:
>
> def main():
> a = ['a list','with','three elements']
> print a
> print fnc1(a)
On 5/30/2011 5:08 AM, Laurent Claessens wrote:
Le 30/05/2011 11:02, Terry Reedy a écrit :
On 5/30/2011 3:38 AM, Laurent wrote:
Cool. I was thinking that "5" was the name, but
>>> 5.__add__(6)
File "", line 1
5.__add__(6)
Try 5 .__add__(6)
What is the rationale behind the fact to add a spa
Laurent Claessens writes:
> Le 30/05/2011 11:02, Terry Reedy a écrit :
> > On 5/30/2011 3:38 AM, Laurent wrote:
> >
> >> Cool. I was thinking that "5" was the name, but
> >> >>> 5.__add__(6)
> >> File "", line 1
> >> 5.__add__(6)
> >
> >
> > Try 5 .__add__(6)
>
> What is the rationale behind
What is the rationale behind the fact to add a space between "5" and
".__add__" ?
Why does it work ?
It's a hint for the tokenizer.
I didn't know the tokenizer. Now I understand.
Thanks
Laurent
--
http://mail.python.org/mailman/listinfo/python-list
What is the rationale behind the fact to add a space between "5" and
".__add__" ?
Why does it work ?
It's a hint for the tokenizer.
I didn't know the tokenizer. Now I understand.
Thanks
Laurent
--
http://mail.python.org/mailman/listinfo/python-list
Laurent Claessens wrote:
> Le 30/05/2011 11:02, Terry Reedy a écrit :
>> On 5/30/2011 3:38 AM, Laurent wrote:
>>
>>> Cool. I was thinking that "5" was the name, but
>>> >>> 5.__add__(6)
>>> File "", line 1
>>> 5.__add__(6)
>>
>>
>> Try 5 .__add__(6)
>
> What is the rationale behind the fact
Laurent Claessens writes:
> Le 30/05/2011 11:02, Terry Reedy a écrit :
> > Try 5 .__add__(6)
>
> What is the rationale behind the fact to add a space between "5" and
> ".__add__" ?
> Why does it work ?
Try asking it the other way around. Why doesn't ‘5.__add__(6)’, without
the space, work?
--
On Mon, 30 May 2011 09:12:50 +0200, Laurent Claessens wrote:
> Could you give an example of an object that has no name ? I've missed
> something ...
>>> mylist = [None, 42, "something"]
The list object has a name, mylist.
The three objects inside the list have no names.
--
Steven
--
http:
On Mon, 30 May 2011 11:08:23 +0200, Laurent Claessens wrote:
> Le 30/05/2011 11:02, Terry Reedy a écrit :
>> On 5/30/2011 3:38 AM, Laurent wrote:
>>
>>> Cool. I was thinking that "5" was the name, but
>>> >>> 5.__add__(6)
>>> File "", line 1
>>> 5.__add__(6)
>>
>>
>> Try 5 .__add__(6)
>
> W
Le 30/05/2011 11:02, Terry Reedy a écrit :
On 5/30/2011 3:38 AM, Laurent wrote:
Cool. I was thinking that "5" was the name, but
>>> 5.__add__(6)
File "", line 1
5.__add__(6)
Try 5 .__add__(6)
What is the rationale behind the fact to add a space between "5" and
".__add__" ?
Why does
On 5/30/2011 3:38 AM, Laurent wrote:
Cool. I was thinking that "5" was the name, but
>>> 5.__add__(6)
File "", line 1
5.__add__(6)
Try 5 .__add__(6)
Modules, classes, and functions have a .__name__ attribute (I call it
their 'definition name') used to print a representation. As best I can
On Mon, May 30, 2011 at 6:12 PM, Laurent Claessens wrote:
> Could you give an example of an object that has no name ? I've missed
> something ...
>>> object()
--
With best regards,
Daniel Kluev
--
http://mail.python.org/mailman/listinfo/python-list
Could you give an example of an object that has no name ? I've missed
something ...
def foo():
return 5
print(foo())
The int object 5 has no name here.
Cool. I was thinking that "5" was the name, but
>>> 5.__add__(6)
File "", line 1
5.__add__(6)
^
SyntaxError: inva
On Mon, May 30, 2011 at 12:12 AM, Laurent Claessens wrote:
> Le 29/05/2011 23:42, Ben Finney a écrit :
>> Peter Pearson writes:
>>
>>> Python works in terms of objects having names, and one
>>> object can have many names.
>>
>> Or no names. So it's less accurate (though better than talking of
>
Le 29/05/2011 23:42, Ben Finney a écrit :
Peter Pearson writes:
Python works in terms of objects having names, and one
object can have many names.
Or no names. So it's less accurate (though better than talking of
“variables”) to speak of Python objects “having names”.
Could you give an e
On Mon, 30 May 2011 11:31:33 +1000, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> http://mail.python.org/pipermail/tutor/2010-December/080505.html
>>
>>
>> Constructive criticism welcome.
>
> Informative, but it “buries the lead” as our friends in the press corps
> would say.
Thank you, tha
On Mon, May 30, 2011 at 12:08 PM, Ben Finney wrote:
> Chris Angelico writes:
>
>> Of course, there's a significant difference between a mailing list
>> post and a detailed and well copyedited article. Quite frequently I'll
>> ramble on list, in a way quite inappropriate to a publication that
>> w
Chris Angelico writes:
> Of course, there's a significant difference between a mailing list
> post and a detailed and well copyedited article. Quite frequently I'll
> ramble on list, in a way quite inappropriate to a publication that
> would be linked to as a "hey guys, here's how it is" page. Di
On Mon, May 30, 2011 at 11:31 AM, Ben Finney wrote:
> http://www.computerworld.com/s/article/print/93903/I_m_OK_The_Bull_Is_Dead>
I agree with the gist of that. My take on this is: When I'm talking to
my boss, I always assume that the phone will ring ten seconds into my
explanation. Ten seconds
Steven D'Aprano writes:
> http://mail.python.org/pipermail/tutor/2010-December/080505.html
>
>
> Constructive criticism welcome.
Informative, but it “buries the lead” as our friends in the press corps
would say.
Instead you should write as though you have no idea where the reader
will stop rea
On Sun, 29 May 2011 04:30:52 -0400, Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a
> program. The made-up code snippet below illustrates the problem I
> encountered:
[...]
> Are there others who feel as I do that a function parameter should
> always be loca
On 5/29/2011 4:19 PM, Henry Olders wrote:
From my perspective, a function parameter should be considered as
having been assigned (although the exact assignment will not be known
until runtime), and as an assigned variable, it should be considered
local.
That is exactly the case for Python func
On Sun, 29 May 2011 16:19:11 -0400
Henry Olders wrote:
> > def fnc2(c):
> > c = c[:]
> >c[1] = 'having'
> >return c
>
> Thank you, Wolfgang. That certainly works, but to me it is still a
> workaround to deal with the consequence of a particular decision.
> From my per
Peter Pearson writes:
> Python works in terms of objects having names, and one
> object can have many names.
Or no names. So it's less accurate (though better than talking of
“variables”) to speak of Python objects “having names”.
> The names b and c aren't boxes that hold things, they are -- i
On 5/29/2011 7:59 AM, Mel wrote:
Henry Olders wrote:
I just spent a considerable amount of time and effort debugging a program.
The made-up code snippet below illustrates the problem I encountered:
def main():
a = ['a list','with','three elements']
print a
print fnc1(a)
print a
def fnc1(b):
r
Henry
On 2011-05-29, at 5:47 , Wolfgang Rohdewald wrote:
> On Sonntag 29 Mai 2011, Henry Olders wrote:
>> It seems that in Python, a variable inside a function is
>> global unless it's assigned.
>
> no, they are local
>
>> I would have thought that a function parameter would
>> automaticall
On Mon, May 30, 2011 at 4:53 AM, Steven D'Aprano
wrote:
> UnboundLocalError is a subclass of NameError, so it will still be caught
> by try...except NameError.
>
> If you're crazy enough to be catching NameError :)
Ah okay. So it is still NameError, it just doesn't look like one.
> While Unbound
On Sun, May 29, 2011 at 12:38 PM, Chris Angelico wrote:
> I thought it basically functioned top-down. You get a different error
> on the print line if there's a "bar = 42" *after* it. This could make
> debugging quite confusing.
>
> Guess it's just one of the consequences of eschewing variable
> d
On Mon, 30 May 2011 04:38:26 +1000, Chris Angelico wrote:
> On Mon, May 30, 2011 at 4:01 AM, Chris Rebert wrote:
>> def foo():
>> print bar
>> bar = 42
>>
>> foo()
>>
>> ===>
>> Traceback (most recent call last):
>> File "", line 1, in
>> File "", line 2, in foo
>> UnboundLocalError: loc
On Mon, May 30, 2011 at 4:01 AM, Chris Rebert wrote:
> def foo():
> print bar
> bar = 42
>
> foo()
>
> ===>
> Traceback (most recent call last):
> File "", line 1, in
> File "", line 2, in foo
> UnboundLocalError: local variable 'bar' referenced before assignment
Wow
I thought it basica
On Mon, 30 May 2011 03:53:24 +1000, Chris Angelico wrote:
> On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano
> wrote:
>> If a name is assigned to anywhere in the function, treat it as a local,
>> and look it up in the local namespace. If not found, raise
>> UnboundLocalError.
>>
>>
> Wait wha? I
On Sun, May 29, 2011 at 10:53 AM, Chris Angelico wrote:
> On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano
> wrote:
>> If a name is assigned to anywhere in the function, treat it as a local,
>> and look it up in the local namespace. If not found, raise
>> UnboundLocalError.
>>
>
> Wait wha? I've
On Sun, May 29, 2011 at 10:47 PM, Steven D'Aprano
wrote:
> If a name is assigned to anywhere in the function, treat it as a local,
> and look it up in the local namespace. If not found, raise
> UnboundLocalError.
>
Wait wha? I've never seen this... wouldn't it just create it in the
local namespac
On Sun, 29 May 2011 04:30:52 -0400, Henry Olders wrote:
[snip]
> def main():
> a = ['a list','with','three elements']
> print a
> print fnc1(a)
> print a
>
> def fnc1(b):
> return fnc2(b)
>
> def fnc2(c):
> c[1] = 'having'
> return c
>
> This is the
On Sun, 29 May 2011 11:47:26 +0200, Wolfgang Rohdewald wrote:
> On Sonntag 29 Mai 2011, Henry Olders wrote:
>> It seems that in Python, a variable inside a function is global unless
>> it's assigned.
>
> no, they are local
I'm afraid you are incorrect. Names inside a function are global unless
Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a program.
> The made-up code snippet below illustrates the problem I encountered:
>
> def main():
> a = ['a list','with','three elements']
> print a
> print fnc1(a)
> print a
>
> def fnc1(b):
> return fnc2(b)
On Sun, May 29, 2011 at 1:30 AM, Henry Olders wrote:
> I just spent a considerable amount of time and effort debugging a program.
> The made-up code snippet below illustrates the problem I encountered:
>
> def main():
> a = ['a list','with','three elements']
> print a
> print
On Sonntag 29 Mai 2011, Henry Olders wrote:
> It seems that in Python, a variable inside a function is
> global unless it's assigned.
no, they are local
> I would have thought that a function parameter would
> automatically be considered local to the function. It doesn't
> make sense to me to pas
On 8/20/2010 12:56 PM, M B wrote:
fre 2010-08-20 klockan 13:19 -0600 skrev Burton Samograd:
M B writes:
Hi,
dept=0
def mud():
print dept
mud()
0
def mud():
dept+=1
print dept
You should add a global statement or else python thinks a variable used
is a
fre 2010-08-20 klockan 13:19 -0600 skrev Burton Samograd:
> M B writes:
>
> > Hi,
> dept=0
> def mud():
> > print dept
> >
> >
> mud()
> > 0
> def mud():
> > dept+=1
> > print dept
>
> You should add a global statement or else python thinks a variable used
>
M B writes:
> Hi,
dept=0
def mud():
> print dept
>
>
mud()
> 0
def mud():
> dept+=1
> print dept
You should add a global statement or else python thinks a variable used
is a local:
>>> def mud():
global dept
dept+=1
print dept
-
On Aug 20, 8:25 pm, Chris Rebert wrote:
> On Fri, Aug 20, 2010 at 11:09 AM, M B wrote:
> > Hi,
> > I try to learn python.
> > I don't understand this:
>
> dept=0
>
> def mud():
> > dept+=1
> > print dept
>
> mud()
> > Traceback (most recent call last):
> > File "",
1 - 100 of 196 matches
Mail list logo
