➜
This issue trackerhas been migrated toGitHub, and is currentlyread-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.
Created on2020-02-07 14:44 bylys.nikolaou, last changed2022-04-11 14:59 byadmin. This issue is nowclosed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 18405 | merged | lys.nikolaou,2020-02-07 14:57 | |
| PR 18408 | merged | lys.nikolaou,2020-02-08 00:04 | |
| Messages (5) | |||
|---|---|---|---|
| msg361595 -(view) | Author: Lysandros Nikolaou (lys.nikolaou)* | Date: 2020-02-07 14:44 | |
There is a problem with the end_col_offset of nested Attribute nodes in decorators. For example, parsing@a.b.cdef f(): passproduces the following AST tree (part):decorator_list=[ Attribute( value=Attribute( value=Name( , ctx=Load(), lineno=1, col_offset=1, end_lineno=1, end_col_offset=2, ), attr="b", ctx=Load(), lineno=1, col_offset=1, end_lineno=1, *end_col_offset=6*, ), attr="c", ctx=Load(), lineno=1, col_offset=1, end_lineno=1, end_col_offset=6, )],Note that the Attribute node with attr="b" has end_col_offset=6, while it should actually be 4. | |||
| msg361614 -(view) | Author: Guido van Rossum (gvanrossum)* | Date: 2020-02-07 23:36 | |
New changesetd2e1098641f98594702ef29049c3c4a3f394786f by Lysandros Nikolaou in branch 'master':bpo-39579: Fix Attribute end_col_offset to point at the current node (GH-18405)https://github.com/python/cpython/commit/d2e1098641f98594702ef29049c3c4a3f394786f | |||
| msg361617 -(view) | Author: miss-islington (miss-islington) | Date: 2020-02-08 00:21 | |
New changeset8b9cebce09cb6919fdb97d8e608288a503681d13 by Lysandros Nikolaou in branch '3.8':[3.8]bpo-39579: Fix Attribute end_col_offset to point at the current node (GH-18405) (GH-18408)https://github.com/python/cpython/commit/8b9cebce09cb6919fdb97d8e608288a503681d13 | |||
| msg372796 -(view) | Author: Francis Herne (flherne) | Date: 2020-07-01 22:27 | |
Note: this change causes a regression in kdev-python because our code was based on (and worked around) the long-standing previous behaviour; it produces broken results given the 'fixed' offset.I shall have to write a patch with a version-check before our next stable release.While the new behaviour is more logical, I'm not convinced that deliberate API breakage in a stable release - for something that's not a recent regression - was a good idea. | |||
| msg372799 -(view) | Author: Francis Herne (flherne) | Date: 2020-07-02 00:19 | |
Sorry, on further inspection it was the other AST range changehttps://bugs.python.org/issue39474 , not this one. | |||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:26 | admin | set | github: 83760 |
| 2020-07-02 00:19:06 | flherne | set | messages: +msg372799 |
| 2020-07-01 22:27:37 | flherne | set | nosy: +flherne messages: +msg372796 |
| 2020-02-08 00:22:17 | gvanrossum | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
| 2020-02-08 00:21:47 | miss-islington | set | nosy: +miss-islington messages: +msg361617 |
| 2020-02-08 00:04:54 | lys.nikolaou | set | pull_requests: +pull_request17783 |
| 2020-02-07 23:36:35 | gvanrossum | set | messages: +msg361614 |
| 2020-02-07 14:57:54 | lys.nikolaou | set | keywords: +patch stage: patch review pull_requests: +pull_request17781 |
| 2020-02-07 14:44:54 | lys.nikolaou | create | |