[Feature] new lint rule to require that each block must end with # or #. (HashtagDot) or a new line.

[EdSaleh]

Hello,

Please create a new lint rule to require that each block must end with # or #. or a new line.
This would work as a curly braces blocks found in C style languages.
Also, this could also be used to reformat python code by code editor to fix any indentation issues.

Users can also use a different word symbol or use a new line for this purpose. (#., #, #/, newline, etc). The user has the option to select the keyword they would like to have for the project. The difference between this proposal (:\n code_block \n#.) and curly braces ({}) in C languages is that curly braces are also indentation insensitive while this proposal is indentation sensitive just like indentation style languages.

There could also be a configurable threshold limit for block lines for which the code_block_ending_marker rule is activated and would apply (example: block_lines > 1 lines by default).
Users can also use new line instead of # or #. by configuring code_block_ending_marker_word if it fits their project development.

Example:

import string
def atbash(sequence: str) -> str:
    """
    Example
    """
    output = ""
    for i in sequence:
        extract = ord(i)
        if 65 <= extract <= 90:
            output += chr(155 - extract)
        #.
        elif 97 <= extract <= 122:
            output += chr(219 - extract)
        #.
        else:
            output += i
        #.
    #.
    return output
#.

There are cases where strict block guarantees is required. Also, when copying python code sometimes spacing is not aligned correctly and having code with this style with editor support, editor would fix incorrect spacing easily.

if(True):
print(True)
print(True)
#
if(True):
print(True)
print(True)
#

OR

if(True):
print(True)
print(True)
#.
if(True):
print(True)
print(True)
#.

would be aligned correctly by the editor to:

if(True):
 print(True)
 print(True)
#
if(True):
 print(True)
 print(True)
#

OR

if(True):
 print(True)
 print(True)
#.
if(True):
 print(True)
 print(True)
#.

Thank you,

[AlexWaygood]

Hi, thanks for the suggestion! Unfortunately, I think very few of our users would want to switch this rule on, essentially for the same reasons explained to you by the pylint maintainers in pylint-dev/pylint#9684. As such, I think this probably wouldn't be worth the maintenance burden for us, unfortunately. So we'll decline this one :-)

[EdSaleh]

Hi, thanks for the suggestion! Unfortunately, I think very few of our users would want to switch this rule on, essentially for the same reasons explained to you by the pylint maintainers in pylint-dev/pylint#9684. As such, I think this probably wouldn't be worth the maintenance burden for us, unfortunately. So we'll decline this one :-)

Sure, but I don't think issues from a different project should be relavent here. The purpose of this issue is to let python and other language developers know of this idea and to create a discussion around it, discussion to identify whether this feature could be useful or not and why, and the decision around it is for the project developers to choose.

[EdSaleh]

I have some experience with creating proposal for lints, I have also contributed to rust lint previously and my proposal was completed and merged.
rust-lang/rust-clippy#2685

[zanieb]

Hi!

We use issues from other projects (pylint, flake8, black, etc.) to help inform our design decisions here because we want to have cohesion between various tools in the Python ecosystem.

However, regardless of the issue in pylint, I think that this rule would not be used by most of our users and is antithetical to general Python design principles. It is currently out of scope for what we'd want to include in Ruff. Maybe once we have support for plugins, it'd make sense there.

I have no problem with discussion continuing around this idea. Anyone is welcome to comment in this issue.