Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Mon, 15 Oct 2012 12:39:18 +1100
From: Cameron Simpson <cs@zip.com.au>
To: Ian Kelly <ian.g.kelly@gmail.com>
Subject: Re: trouble with nested closures: one of my variables is missing...
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALwzidnLyvNuneWH0ifGP-ob2iagqbsduqZVtPqfHsAn1QJymQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
References: <CALwzidnLyvNuneWH0ifGP-ob2iagqbsduqZVtPqfHsAn1QJymQ@mail.gmail.com>
Cc: Python <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2190.1350265161.27098.python-list@python.org>
Lines: 59
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:31273

On 14Oct2012 19:27, Ian Kelly <ian.g.kelly@gmail.com> wrote:
| On Sun, Oct 14, 2012 at 7:08 PM, Cameron Simpson <cs@zip.com.au> wrote:
| > Is attr_name omitted from locals() in made_file_property _because_ I
| > have an assignment statement?
| 
| Yes.  Syntactically, a variable is treated as local to a function if
| it is assigned to somewhere in that function and there is no explicit
| global or nonlocal declaration.

Aha. Good.

| > If that's the case, should I be doing this (using distinct names for the
| > closure variable and the function local variable):
| >
| >   def make_file_property(attr_name=None, unset_object=None, poll_rate=1):
[...]
| >       if attr_name is None:
| >         my_attr_name = '_' + func.__name__
| >       else:
| >         my_attr_name = attr_name
[...]
| > i.e. deliberately _not_ assigning to attr_name as as to _avoid_ masking
| > the outer attr_name from the inner locals()?
| >
| > BTW, doing that works. Is that The True Path for this situation?
| 
| That's a perfectly good way to do it as long as you don't want to
| actually change the value of the outer attr_name.

Well, I don't need to - using a distinct local variable will do the job.  I
just hadn't realised I needed the extra level of naming.

| If you did, then
| you would either declare the variable as nonlocal (Python 3.x only)

... which is why I couldn't find such in the 2.7.3 doco ...

| or
| use a container (e.g. a 1-element list), which would allow you to
| modify the contents of the container without actually assigning to the
| variable.

Ah. Yeah, tacky; I've done that kind of thing in the past on occasion but
using a distinct local name is much cleaner here, and probably usually.

| > If so, I think I now understand what's going on: Python has inspected
| > the inner function and not placed the outer 'attr_name' into locals()
| > _because_ the inner function seems to have its own local attr_name
| > in use, which should not be pre-tromped.
| 
| Exactly right.

Thanks for the explaination. Now I know a New Thing.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

"Vy can't ve chust climb?"  - John Salathe