You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First for all thanks for this fork. While black does a good job, the lack of some configuration freedom and the project's unwillingness to move away from the accepted dogmas towards a bit of greyness is discouraging to me. All the more I'm glad to find a different approach in this fork.
The Problem
In my projects, I often group logical code pieces inside functions and methods with single empty lines. The eyes cling better to such groups. Top-level functions are separated by two lines, so all the code looks well structured to me. Unfortunately, the PEP8 recommendation is that methods should be separated by only one line. I don't like the result especially if methods get bigger and more complex.
I have two feature suggestions for the project, the implementation of either of them I would be very happy with:
1. --force-double-lines-between-methods
The formatter preemptively insert two empty lines between methods.
2. --keep-double-lines-between-methods
My proffered behavior, the code formatter takes into account the number of empty lines between methods left by user and not interfere if there are two or one.
Attempted solution
For the moment the task did not seem so difficult to me. I prototyped the first feature relatively quickly in this branch. Empty lines handling is done in lines.py in top-down manner. This is a bit of a problem, because the decision to surround a method with empty lines is made only when the method is declared, and the empty lines are inserted just before the method. There are quite rare situations when there is other code block in the class besides methods, and then this approach gives unsatisfactory results. Here is a short abstract example (I don't know why some one would prefer to do something like this, but it's valid code):
The second feature is more difficult to implement, because formatter should track the state of the second last line. It also means there will be more divergence from black and the feature won't be as atomic anymore.
Thoughts and questions
I don't know if the cercis project is interested in this idea, I think more customization possibilities would be beneficial. I would love to see this feature in cercis. I would also appreciate any help in implementation and testing. With the last I have some troubles to find the right entry points.
The text was updated successfully, but these errors were encountered:
Thanks
First for all thanks for this fork. While black does a good job, the lack of some configuration freedom and the project's unwillingness to move away from the accepted dogmas towards a bit of greyness is discouraging to me. All the more I'm glad to find a different approach in this fork.
The Problem
In my projects, I often group logical code pieces inside functions and methods with single empty lines. The eyes cling better to such groups. Top-level functions are separated by two lines, so all the code looks well structured to me. Unfortunately, the PEP8 recommendation is that methods should be separated by only one line. I don't like the result especially if methods get bigger and more complex.
I have two feature suggestions for the project, the implementation of either of them I would be very happy with:
1. --force-double-lines-between-methods
The formatter preemptively insert two empty lines between methods.
2. --keep-double-lines-between-methods
My proffered behavior, the code formatter takes into account the number of empty lines between methods left by user and not interfere if there are two or one.
Attempted solution
For the moment the task did not seem so difficult to me. I prototyped the first feature relatively quickly in this branch. Empty lines handling is done in
lines.py
in top-down manner. This is a bit of a problem, because the decision to surround a method with empty lines is made only when the method is declared, and the empty lines are inserted just before the method. There are quite rare situations when there is other code block in the class besides methods, and then this approach gives unsatisfactory results. Here is a short abstract example (I don't know why some one would prefer to do something like this, but it's valid code):The second feature is more difficult to implement, because formatter should track the state of the second last line. It also means there will be more divergence from black and the feature won't be as atomic anymore.
Thoughts and questions
I don't know if the cercis project is interested in this idea, I think more customization possibilities would be beneficial. I would love to see this feature in cercis. I would also appreciate any help in implementation and testing. With the last I have some troubles to find the right entry points.
The text was updated successfully, but these errors were encountered: