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

[EdSaleh]

Current problem

[Feature] new lint rule to require a comment #. at end each python block.

Desired solution

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,

Additional context

No response

[Pierre-Sassoulas]

Please don't reopen closed issues.

[EdSaleh]

Please don't reopen closed issues.

@Pierre-Sassoulas
I added new info to the topic.
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.

I have also contributed to rust lint previously and my proposal was completed and merged.
rust-lang/rust-clippy#2685

As suggested, I will be looking into creating a plugin for this feature.

[DanielNoord]

You did not contribute, it was written by somebody else, and the largest discussion in that PR was about how to correctly phrase why it was such a bad lint (rust-lang/rust-clippy#3494).

I also see you link to that issue in various other repositories (modularml/mojo#2929 and astral-sh/ruff#11698) where you have received similar negative responses. To keep all open source maintainers from going insane and spending too much time on your unnecessary issues and comments consider this your last warning before I ban you from this organisation and report you for spamming various repositories.

Read up on tools your opening issues against, see what they design philosophy is and act like the maintainers ask you to.

Good luck with writing your plugin! I hope to see it on PyPI one day 😄

[EdSaleh]

You did not contribute, it was written by somebody else, and the largest discussion in that PR was about how to correctly phrase why it was such a bad lint (rust-lang/rust-clippy#3494).

I also see you link to that issue in various other repositories (modularml/mojo#2929 and astral-sh/ruff#11698) where you have received similar negative responses. To keep all open source maintainers from going insane and spending too much time on your unnecessary issues and comments consider this your last warning before I ban you from this organisation and report you for spamming various repositories.

Read up on tools your opening issues against, see what they design philosophy is and act like the maintainers ask you to.

Good luck with writing your plugin! I hope to see it on PyPI one day 😄

I posted the proposal to different project since I see it could be useful for these projects as well, with similar indentation code block code style, and an average person knows the difference between spamming and discussing.

My rust lint proposal is the older and first one, and it's marked completed and merged as stated on the issue. I didn't code it though. Let's continue with pylint here. As I said, I am looking into implementing a plugin for this feature.

[EdSaleh]

You did not contribute, it was written by somebody else, and the largest discussion in that PR was about how to correctly phrase why it was such a bad lint (rust-lang/rust-clippy#3494).

I also see you link to that issue in various other repositories (modularml/mojo#2929 and astral-sh/ruff#11698) where you have received similar negative responses. To keep all open source maintainers from going insane and spending too much time on your unnecessary issues and comments consider this your last warning before I ban you from this organisation and report you for spamming various repositories.

Read up on tools your opening issues against, see what they design philosophy is and act like the maintainers ask you to.

Good luck with writing your plugin! I hope to see it on PyPI one day 😄

Hello,
I'm not sure why would you deal funnily or sarcastically with this proposal (hashdot for indentation code block). This is not a good environment for proposals or new ideas. I am just proposing an idea that I think could be helpful for some people, particularly people coming for C style languages, while following python syntax and conventions and it's your decision at the end whether to accept it or not for this proposal.
I think python, particularly its syntax is an amazing language for nearly everything as it's the nearest to natural language and that's the reason for its wide spread use in many fields.
Finally, my proposal is complete now, and there aren't anything more to add to it or any discussion regarding it.
Thank you,