AST Parsed Decorator: col_offset Value for Decorator is Function Position +1.

[horw]

Bug report

Bug description:

import ast

code = """
@lala
def some_function():
    pass
"""

parsed_code = ast.parse(code)

fn = parsed_code.body[0]
print(fn.name, fn.col_offset)
dc = fn.decorator_list[0]
print(dc.id, dc.col_offset)

Output:

some_function 0
lala 1

CPython versions tested on:

3.11

Operating systems tested on:

Linux

[skirpichev]

@horw, what you expected?

Does make sense for me, e.g.:

>>> import ast
... 
... code = """
... @  lala
... def some_function():
...     pass
... """
... 
... parsed_code = ast.parse(code)
... 
... fn = parsed_code.body[0]
... print(fn.name, fn.col_offset)
... dc = fn.decorator_list[0]
... print(dc.id, dc.col_offset)
... 
some_function 0
lala 3

[horw]

I expect it to count the '@' position.

[skirpichev]

Why?

[skirpichev]

CC @Eclips4

[picnixz]

For instance:

@foo
def    bar(): pass

has the following dump:

Module(
  body=[
    FunctionDef(
      name='bar',
      args=arguments(),
      body=[
        Pass(
          lineno=2,
          col_offset=14,
          end_lineno=2,
          end_col_offset=18)],
      decorator_list=[
        Name(
          id='foo',
          ctx=Load(),
          lineno=1,
          col_offset=1,
          end_lineno=1,
          end_col_offset=4)],
      lineno=2,
      col_offset=0,
      end_lineno=2,
      end_col_offset=18)])

As you can see, the col_offset for the def keyword is 0 and not something else, namely FunctionDef nodes are characterized by the position of their def and not the position of the function name. On the other hand, the decorator list is not a node per se, but can be seen as a "scope" containing some names. In the above example, the identifier 'foo' is a Name node (not some (non-existing) DecoratorNode). Therefore, it is correct that its column offset is 1 and not 0.

In a more detailed manner, you can think of FunctionDef as being a node with a name and a decorator list as being a list of nodes. Since the column offset is always for a node, the result is as expected.

[Eclips4]

Hello!
I agree with @picnixz's explanation. This behavior is expected :)

[horw]

Thank you for the explanation!