Given the following code:

class MyClass(object):

    @property
    def my_function(self): pass

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)

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.

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?

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?

I was hoping to see if this was seen as a reasonable patch that might be accepted.

I didn't look carefully but superficially it looks reasonable, so it is worth trying.

Also, while I think it would be nice, I take it a patch for this would be unlikely to be backported, right?

I think this is unlikely because it affects some public APIs.

In my PR, I added def_lineno and class_lineno as fields in the ASDL, instead of attributes (since constructors cannot have attributes, only types can). This means they show up in ast.dump which 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.

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?).

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.