[issue23824] in-place addition of a shadowed class field
New submission from Jethro: Look at this simple code: class A: tot = 0 def __init__(self, a): self.tot += a x = A(3) print(x.tot, A.tot) Result from print: 3 0 What the interpreter did was that it first resolved self.tot to be the class field tot, which resolves to 0, then it created an instance field tot to hold the result 3. This is not correct, as one single self.tot meant two different things. Two ways to fix this: 1. report a name undefined error (interpret self.tot as instance field) 2. increase A.tot (interpret self.tot as class field) Clearly 1 seems more naturally to Python, even though I wished python could disallow a class field to be shadowed by instance field, which seems quite a reasonable thing to do. -- components: Interpreter Core messages: 239714 nosy: jethro priority: normal severity: normal status: open title: in-place addition of a shadowed class field type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue23824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23824] in-place addition of a shadowed class field
Jethro added the comment: I believe Mr. Murray somehow missed the point. My point is that the very same self.tot is interpreted as two different things: instance field and class field. In another analogous case, the interpreter would be more consistent: >>> tot = 0 >>> def addtot(x): tot+=x >>> addtot(3) If this tot is allowed to be resolved to different things, there should be no problem. Instead you get an error: Traceback (most recent call last): File "", line 1, in addtot(3) File "", line 1, in addtot def addtot(x): tot += x UnboundLocalError: local variable 'tot' referenced before assignment -- ___ Python tracker <http://bugs.python.org/issue23824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23824] in-place addition of a shadowed class field
Changes by Jethro : -- resolution: not a bug -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue23824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23824] in-place addition of a shadowed class field
Jethro added the comment: I'm not confused. In my first report, I have already explained why python behaves that way. My point is, this is not the right way to go. Because the very same self.tot in the in-place operation self.tot+=a is first resolved to be the class field, then an instance field. This is against any sensible design of a language. If this is OK, then my second example should also be OK. In my second example, tot += x, the very same tot can be first resolved to the global variable tot, then the result is assigned to a local variable. -- resolution: not a bug -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue23824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
