lineno and col_offset are wrong on function definitions with decorators #77392
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2018-11-23.02:24:00.523>
created_at = <Date 2018-04-03.05:13:29.303>
labels = ['3.7', '3.8', 'type-bug', 'library']
title = 'lineno and col_offset are wrong on function definitions with decorators'
updated_at = <Date 2018-11-23.02:24:00.522>
user = 'https://github.com/gforcada'bugs.python.org fields:
activity = <Date 2018-11-23.02:24:00.522>
actor = 'levkivskyi'
assignee = 'none'
closed = True
closed_date = <Date 2018-11-23.02:24:00.523>
closer = 'levkivskyi'
components = ['Library (Lib)']
creation = <Date 2018-04-03.05:13:29.303>
creator = 'gforcada'
dependencies = []
files = []
hgrepos = []
issue_num = 33211
keywords = ['patch']
message_count = 8.0
messages = ['314861', '314864', '314906', '315008', '315046', '315074', '330181', '330291']
nosy_count = 6.0
nosy_names = ['eric.smith', 'serhiy.storchaka', 'levkivskyi', 'ethan smith', 'nitishch', 'gforcada']
pr_nums = ['6410', '6460', '9731']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33211'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5', 'Python 3.6', 'Python 3.7', 'Python 3.8']
Activity
gforcada commentedon Apr 3, 2018
Given the following code:
Parsing it with ast module, the lineno and col_offset of the ast.FunctionDef is reported to be where the decorator starts (i.e. line 3 column 4) rather than where the actual def statement is (i.e. line 4 column 4).
This is due to the decorator that is part of the ast.FunctionDef, but as there can be multiple decorators (which they don't provide their own lineno and col_offset arguments) and they can span across multiple lines, there is no reliable way to actually know where the actual def statement starts physically.
See this bug report on flake8-builtins plugin (I'm the author) reported by @dhood user on github:
gforcada/flake8-builtins#22 (comment)
serhiy-storchaka commentedon Apr 3, 2018
See how similar issue was solved in Pyflakes: PyCQA/pyflakes#273.
Python tests also needed special workaround, see Lib/test/test_sys_settrace.py and bpo-17288.
ethanhs commentedon Apr 3, 2018
There is also a relevant mypy bug report python/mypy#3871. This seems like a common problem for tools working on the AST. The relevant code seems to be https://github.com/python/cpython/blob/master/Python/ast.c#L1695.
Would a possible solution be adding a decorated_lineno attribute to decorated ast nodes?
ethanhs commentedon Apr 5, 2018
I have a branch with an implementation of my suggestion here: https://github.com/ethanhs/cpython/tree/decorlineno
I was hoping to see if this was seen as a reasonable patch that might be accepted.
Also, while I think it would be nice, I take it a patch for this would be unlikely to be backported, right?
ilevkivskyi commentedon Apr 7, 2018
I didn't look carefully but superficially it looks reasonable, so it is worth trying.
I think this is unlikely because it affects some public APIs.
ethanhs commentedon Apr 7, 2018
In my PR, I added
def_linenoandclass_linenoas fields in the ASDL, instead of attributes (since constructors cannot have attributes, only types can). This means they show up inast.dumpwhich is probably not the desired behavior, as it makes the dumped ast whitespace/line offset sensitive.Therefore I propose we change the line number of the nodes to be the one of the def/class statement. It seems based on this commit that the change was done to fix inspect.getsource (so that it started on the first decorator), but I think it is much more logical for inspect to handle decorated items instead of having the ast lie.
One other option could be for a modified ast to have a decorated node, which holds the decorator list, and the class/function. This has the possible downside of being a not-insignificant change to the ast.
serhiy-storchaka commentedon Nov 21, 2018
Sorry, I forgot about this issue and independently made similar changes in bpo-34876. Please rebase your PR and determine whether it contains any useful changes in comparison with the current code (maybe new non-duplicated tests or useful refactoring?).
ethanhs commentedon Nov 23, 2018
This has been fixed, so the issue can be closed I believe.
FWIW I didn't see anything useful to salvage from my PR that wasn't already tested by your tests Serhiy.