feat: Support bundling Python docstrings on attributes #589
Labels
No labels
Compat/Breaking
Kind
Bad merge
Kind
Bug
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
New language
Kind
Security
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: mergiraf/mergiraf#589
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In Python, documentation comments are generally added as "docstrings":
Those "comments" are actual string literals that get pulled in as
__doc__
attributes by Python.Because those string literals aren't marked as
extra
by the tree-sitter grammar, the bundling algorithm does not apply to them. In particular, doc strings for class attributes aren't bundled. This is less of a problem for doc strings for classes or methods, since they already appear in the bloc that defines them, so there is no need for any bundling.To get the doc strings to be bundled with the attributes, I can imagine multiple approaches:
In the case of class attributes (which is the only real case I am aware of where docstring bundling would be useful), there is the additional complication that we are not currently merging those commutatively even without any docstrings, because they are locally indistinguishable from assignments in other sorts of blocks. Both a class body and a function body are just
block
s, and both a class attribute declaration and a variable assignment are justassignment
nodes.In other words:
and
are parsed as two assignments in a
block
.This also begs for a grammar change, I would say. (Not sure if that one is upstream-able…)