Roundup Robot added the comment:
New changeset 94e215a5e24b by Nick Coghlan in branch '3.4':
Issue #24129: Clarify reference docs for name resolution.
https://hg.python.org/cpython/rev/94e215a5e24b
New changeset 5e4d21311772 by Nick Coghlan in branch '3.5':
Merge issue #24129 from 3.4
Nick Coghlan added the comment:
I merged Ivan's latest patch to 3.4/3.5/default. We're unlikely to ever be able
to make these docs completely intuitive (as name resolution is genuinely
complex), but Ivan's revisions at least mean we're no longer assuming readers
know how the name resolution
Nick Coghlan added the comment:
I merged Ivan's latest patch to 3.4/3.5/default. We're unlikely to ever be able
to make these docs completely intuitive (as name resolution is genuinely
complex), but Ivan's revisions at least mean we're no longer assuming readers
know how the name resolution
Changes by Nick Coghlan ncogh...@gmail.com:
--
Removed message: http://bugs.python.org/msg248043
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24129
___
Nick Coghlan added the comment:
The issue tracker was having issues and didn't automatically register the
commits. Links:
3.4: https://hg.python.org/cpython/rev/94e215a5e24b
3.5: https://hg.python.org/cpython/rev/5e4d21311772
default: https://hg.python.org/cpython/rev/e75881393cf2
--
R. David Murray added the comment:
Your ping after a month is very appropriate. It looks like yes, this is
waiting for another review. Based on the fact that the previous patches were
reviewed by core devs and you have responded, I'm moving it to 'commit review',
but I haven't looked at the
Ivan Levkivskyi added the comment:
I am sorry but I still don't get how things are organized here, so pinging this
up. What is the next step? Should I wait for another review?
--
___
Python tracker rep...@bugs.python.org
Ivan Levkivskyi added the comment:
What holds the patch now? Should I do something or just wait?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24129
___
Ivan Levkivskyi added the comment:
It looks like on python-dev
(http://www.mail-archive.com/python-dev@python.org/msg88256.html) there is an
agreement that this behavior should not be changed (at least not in the nearest
future). If there are no more comments/suggestions, then maybe one could
Changes by Evgeny Kapun abacabadabac...@gmail.com:
--
nosy: +abacabadabacaba
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24129
___
___
Ivan Levkivskyi added the comment:
Nick, thank you for a review, I have made a new patch with all the previous
comments taken into account.
--
Added file: http://bugs.python.org/file39759/classdoc-v4.patch
___
Python tracker rep...@bugs.python.org
levkivskyi added the comment:
Eric, the rule that classes don't play the nested scopes game is explained at
beginning of the same section, but the explanation is one sided it only
explains that names defined in classes are not visible inside functions.
Nick, thank you for the thorough
Nick Coghlan added the comment:
The normal rules for name resolution reference here is referring to the name
lookup rules as they existed prior to the introduction of lexical scoping for
functions. It's a dated way of describing it, as the current behaviour of
functions has now been around
Armin Rigo added the comment:
Related to http://bugs.python.org/issue19979 and others mentioned there.
--
nosy: +arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24129
___
Ivan Levkivskyi added the comment:
Eric, I have submitted a new version of the patch. Could you please make a
review? Nick, it will be interesting to hear your opinion too.
I tried to follow such rules:
1. Explanation should be succinct yet clear
2. It should tell as less as possible about
Eric Snow added the comment:
I've left a review. That said, we need to be sure this behavior is
intentional. The fact that it skips the nonlocal scope(s) smells like a bug
to me.
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
Eric Snow added the comment:
I expect you'll get the same response, especially given potential (though
slight) chance for backward-compatibility issues. What I find curious is
Guido's reference to the rule that class bodies don't play the nested
scopes game (and his subsequent explanation).
levkivskyi added the comment:
Eric, thank you for the review. I have incorporated proposed changes in second
version of the patch.
Concerning the question whether it is a bug, it also smells like a bug to me,
but Guido said 13 years ago that this should not be changed:
R. David Murray added the comment:
In this particular case, just wait (now that you have pinged the issue).
Raymond is the most likely person to figure out how to phrase this better, but
it isn't obvious what the best way to explain this is. I don't think your
explanation is exactly
levkivskyi added the comment:
Should I invite someone to review the patch or just wait? How the things are
organized here?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24129
___
levkivskyi added the comment:
Since no one proposed alternative ideas, I am submitting my proposal as a
patch, with the following wording:
A class definition is an executable statement that may use and define names.
Free variables follow the normal rules for name resolution, while unbound
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24129
___
___
New submission from levkivskyi:
The documentation on execution model
https://docs.python.org/3/reference/executionmodel.html contains the statement
A class definition is an executable statement that may use and define names.
These references follow the normal rules for name resolution. The
23 matches
Mail list logo
