Plugin should use lines (or tree), provided by flake8

[peterjc]

Plugin should use lines (or tree), provided by flake8

[peterjc]

I agree - this plugin is a great big hack to glue docutils into flake8.

If you know lots about AST, you could be very well placed to clean this up. If you want to work on this, I would be happy to look at a pull request.

[domdfcoding]

From what I can tell (having used AST very briefly yesterday), the docstring is stored as an ast.Expr object in the "body" of an ast.FunctionDef object representing the function. Classes are presumably represented differently in the AST.

From the ast.Expr object the following can be accessed:

• the docstring text, via the .value.s attribute
• the lineno, via the .lineno attribute
• the col_offset, the the .col_offset attribute

I've put together a rough example of how to extract the docstrings from an AST, modelled after Anthony Sottile's flake8_2020 plugin, so I assume this is the correct way to do it. I imagine this could then be passed to docutils for it to do its thing?

I'll try and explore this further over the weekend.

[peterjc]

That sounds very promising @domdfcoding 👍

[peterjc]

Pull request #33 will clean this up a lot but just importing the pydocstyle parser, but does not address this point directly: We still reparse the Python file when flake8 already did it and can share the AST.

[peterjc]

I made some time to look at this today, what do you think of the code on PR #35 using the AST?

[skirpichev]

Looks good. I've noticed some workarounds for ancient python versions. Maybe it's time to drop this?

[peterjc]

Yeah, the workaround for Python 3.3 and 3.4 was trivial though, so I decided to leave it in for now. I'm expecting and hoping no one complains about my dropping Python 2.7 support yesterday.

[peterjc]

Closed by #35 and the release of v0.2.0, thank you for the suggestion.