classification
Title: Class bodies: when does a name become local?
Type: behavior Stage: resolved
Components: Documentation Versions: Python 3.3, Python 3.4, Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, ezio.melotti, nitika, r.david.murray, terry.reedy
Priority: normal Keywords: patch

Created on 2013-07-16 23:39 by terry.reedy, last changed 2019-05-14 18:06 by xtreak. This issue is now closed.

Files
File name Uploaded Description Edit
issue18478.patch nitika, 2014-03-16 16:54
Messages (7)
msg193205 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-07-16 23:39
http://docs.python.org/3/reference/executionmodel.html#naming-and-binding
says "The following are blocks: ... a class definition." and 

"If a name binding operation occurs anywhere within a code block, all uses of the name within the block are treated as references to the current block. This can lead to errors when a name is used within a block before it is bound. ..." 

This is definitely true for functions, but not for classes:

foo = 'bar'
class C:
    foo = foo

print(C().foo)
#
bar

This is the same for 3.3 and 2.7 with and without '(object)' added. Unless the code is considered to be buggy (probably since forever), the doc should be modified to change 'code block' to 'function code block' or maybe 'module or function code block'. (At near as I can think, the statement is true for modules, but only because globals() == locals(), so that part of the issue does not arise.)
msg213708 - (view) Author: Nitika Agarwal (nitika) * Date: 2014-03-16 04:40
Hey.
I am working on this patch.
msg213737 - (view) Author: Nitika Agarwal (nitika) * Date: 2014-03-16 16:54
Hi,
Please review my patch attached.
msg215608 - (view) Author: Nitika Agarwal (nitika) * Date: 2014-04-05 13:46
Hi,
I have attached the patch for the issue.Please someone review my patch.
msg215624 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-04-05 19:25
After seeing my suggestion applied, I decided I don't like it. Sorry. A 'function code block' is a 'function suite'. A deeper problem is that the revision now omits the rules for classes. The base problem is that I don't know what the rules are when classes and functions are nested within each other (does anybody, without reading the code?). A puzzling example was posted on python-list yesterday, which I will try to find.
msg266655 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-05-30 00:58
As far as I can see this has been fixed by explaining the special rules for class definitions at the end of the section.  Do you think there is anything left to do here, Terry?  Perhaps a 2.7 backport of some of the clarifications?
msg266659 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-30 01:24
The new language *and* organization introduced sometime during 3.4 is good enough for me. " with an exception that unbound local variables are looked up in the global namespace." covers my example. Thanks for the pointer.
History
Date User Action Args
2019-05-14 18:06:10xtreaksetpull_requests: - pull_request13235
2019-05-14 18:04:11xtreaksetpull_requests: + pull_request13235
2019-05-14 16:02:26xtreaksetpull_requests: - pull_request13227
2019-05-14 16:00:32xtreaksetpull_requests: + pull_request13227
2016-05-30 01:24:57terry.reedysetstatus: open -> closed
resolution: out of date
messages: + msg266659

stage: needs patch -> resolved
2016-05-30 00:58:52r.david.murraysetnosy: + r.david.murray
messages: + msg266655
2014-04-05 19:25:05terry.reedysetmessages: + msg215624
2014-04-05 13:46:20nitikasetmessages: + msg215608
2014-03-16 16:54:09nitikasetfiles: + issue18478.patch
keywords: + patch
messages: + msg213737
2014-03-16 04:40:38nitikasetnosy: + nitika
messages: + msg213708
2013-07-16 23:59:44ezio.melottisetnosy: + ezio.melotti
2013-07-16 23:39:14terry.reedycreate