-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ssort messes with class attribute docstrings #70
Comments
Interesting. I wasn't aware of that convention. It's always bugged me that documentation comments appear before the things they describe in code but after in the docs. I don't think this conflicts with any of the other rules for how we sort class bodies so I don't see any harm in implementing it. With that said, it is unlikely to be a straightforward change as we have no precedent for pairing expressions with siblings. I don't have the time to work on this myself, but I'm going to leave this open for you or anyone else to pick up. A PR which implements this behaviour without breaking anything else or tanking performance will be accepted. Happy to provide advice and however many reviews it takes to get something working. In the interim, switching to (Linking to conversation in #11) |
This reverts commit b77f4ee.
Hi @bwhmather, I don't think I have the time to work on this, but could give us some hints where/how this would be implemented, just in case? A quick overview of ssort's flow, with the corresponding modules holding the logic, would be a great start! |
`ssort` re-orders class attributes without taking their docstrings into account. See bwhmather/ssort#70
Before:
After:
There are two PEPs that describe such docstrings. Both of them were rejected.
I know that this is now a "real" docstring syntax but people still use it to document fields in their classes. Some tools support it as well (like sphinx).
It could be useful to recognise such docstrings and preserve their positions.
The text was updated successfully, but these errors were encountered: