Skip to content

feat(extraction): index Python docstrings, not just preceding comments (#1905) - #1909

Closed
maxmilian wants to merge 1 commit into
colbymchenry:mainfrom
maxmilian:fix/1905-python-body-docstrings
Closed

maxmilian wants to merge 1 commit into
colbymchenry:mainfrom
maxmilian:fix/1905-python-body-docstrings

Conversation

@maxmilian

Copy link
Copy Markdown
Contributor

Fixes #1905.

getPrecedingDocstring only walks preceding comment siblings, so a Python docstring — a bare string literal first in the body — never reached the docstring column, never entered nodes_fts, and was never shown by codegraph node. The identical sentence written as a leading # comment was both.

What changed

  • LanguageExtractor gains an optional getBodyDocstring?(), same shape as getSignature?().
  • Every docstring call site in tree-sitter.ts now goes through one docstringFor() helper that consults both sources. A node carrying a comment and a docstring keeps both, joined — two things the author wrote about the same symbol, and the column is free text.
  • Python reads the grammar's string_content rather than slicing quotes off the raw text, so r/u/b prefixes and both """ and ''' forms work without a regex per case. f-strings are skipped: an interpolated string is code, not prose. Dedent follows PEP 257 (first line exempt).

Scoped to Python deliberately. Julia (a string sibling before the def) and Elixir (@doc) fit the same hook; I would rather land one language with the seam proven.

The recall risk, measured

The issue flags that more indexed prose raises recall and can add weak hits. Indexed 117 Python files from docling-core (3,233 nodes) before and after, same queries, top 5:

query before after
flattening nested tables (appears only in a docstring) _collect_subtree_text absent _collect_subtree_text at #2
descendant TableItem TableItem, _draw_table_cells, … identical
MarkdownDocSerializer (exact name) that class at #1 still #1
the (stop word alone) scaled, normalized, … reshuffles entirely

So: the gap closes, name-anchored queries do not degrade, and the churn is confined to a query that was arbitrary in both directions. I am not claiming the stop-word case is unchanged — it isn't — only that it does not displace a real match.

Testing

__tests__/python-body-docstrings.test.ts, 6 cases: the issue's own repro, multi-line dedent, comment + docstring together, single-quote and r-prefixed forms, f-string skipped, and a no-docstring control. Red-armed — reverting python.ts to main turns 4 of them red, leaving the two negative controls green.

Full suite: 259 files / 4,541 passed / 0 failed. tsc --noEmit clean. CHANGELOG entry under [Unreleased] → New Features.

colbymchenry#1905)

getPrecedingDocstring only walks preceding comment siblings, so a Python
docstring — a bare string literal first in the body — never reached the
docstring column, never entered nodes_fts, and was never shown by
`codegraph node`. The identical sentence written as a leading `#` comment was
both. For a Python codebase that is most of the prose there is. (colbymchenry#1905)

Adds an optional getBodyDocstring() to LanguageExtractor, in the same shape as
getSignature(), and routes every docstring call site through one docstringFor()
helper that consults both sources. A node carrying a comment AND a docstring
keeps both, joined: they are two things the author wrote about the same symbol
and the column is free text.

The Python implementation reads the grammar`s string_content rather than
slicing quotes off the raw text, so r/u/b prefixes and both triple-quote forms
work without a regex per case; f-strings are skipped because an interpolated
string is code, not prose. Dedent follows PEP 257 (first line exempt).

Scoped to Python deliberately. Julia (a string sibling before the def) and
Elixir (@doc) fit the same hook and are left as follow-ups.
@colbymchenry

Copy link
Copy Markdown
Owner

Thanks @maxmilian! Your commits here were carried into #2004 (authorship preserved), with a few follow-up changes from review, and that is now merged. Closing this one in favour of it. It will be in the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Python docstrings are never extracted — authored prose is unsearchable (and unshown), while the identical sentence as a # comment is both

2 participants