pylint-dev/pylint

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

EdSaleh opened this issue · 7 comments

Current problem

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

Desired solution

Create a new rule to require that each block must end with # or #.
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 the option to select the keyword they would like to have for the project.

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
#.

Additional context

No response

You should create your custom pylint plugin for that, enforcing a kind of 'end' keyword to make python look like pascal or ada is going to not be pythonic enough / too controversial for pylint core.

You should create your custom pylint plugin for that, enforcing a kind of 'end' keyword to make python look like pascal or ada is going to not be pythonic enough / too controversial for pylint core.

It's not enforcing, it's just an option that would be available if explicit code block is needed. It's disabled by default and only enabled developer when it's required for their project. I think this issue should be discussed even it if it's considered controversial by some.

you can also use a different word symbol or use a new line for this purpose. (#., #/, newline, etc). The user the option to select the keyword they would like to have for the project.

We don't shy away from opinionated checks (like the while checker), but there's such a thing as too opinionated, if something is too opinionated it should be an external pylint plugin.

https://pylint.readthedocs.io/en/stable/development_guide/contributor_guide/governance.html#what-are-the-fundamental-tenets-of-pylint-development

The indentation being implicit begin/end keywords for block is a fundamental property of python, this lint followed closely would make the code less pythonic and thus too opinionated and not suited for pylint core.

If you want to do your own check / plugin you can follow this doc:
https://pylint.readthedocs.io/en/stable/development_guide/how_tos/custom_checkers.html
https://pylint.readthedocs.io/en/stable/development_guide/how_tos/plugins.html

We don't shy away from opinionated checks (like the while checker), but there's such a thing as too opinionated, if something is too opinionated it should be an external pylint plugin.

https://pylint.readthedocs.io/en/stable/development_guide/contributor_guide/governance.html#what-are-the-fundamental-tenets-of-pylint-development

The indentation being implicit begin/end keywords for block is a fundamental property of python, this lint followed closely would make the code less pythonic and thus too opinionated and not suited for pylint core.

If you want to do your own check / plugin you can follow this doc: https://pylint.readthedocs.io/en/stable/development_guide/how_tos/custom_checkers.html https://pylint.readthedocs.io/en/stable/development_guide/how_tos/plugins.html

The issue is not about adding a new feature to the language, it's just a lint rule to be used when strict block indentation is needed for the project, say an enterprise application or other project or style where this is useful.

I'm sure this is a linting rule that almost none of our users would want to turn on. Therefore, we will not add it as it would add to our maintenance burden without providing benefit for our users.

Like @Pierre-Sassoulas linked it should be easy to make a plugin yourself and expose it on PyPI so that anybody who does want it can download it there.

I'm sure this is a linting rule that almost none of our users would want to turn on. Therefore, we will not add it as it would add to our maintenance burden without providing benefit for our users.

Like @Pierre-Sassoulas linked it should be easy to make a plugin yourself and expose it on PyPI so that anybody who does want it can download it there.

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)
#.

Users can also use new line instead of # or #. if they require and configure it to their requirements.

Sorry, if we weren't clear enough, we're not going to maintain checks that go against the fundamental design choices of the python's language. If someone want end block delimiters and the associated benefits, they will use a language end block delimiter to begin with, like Pascal, C, Java or Ada (more likely candidate is ruby: it's actually python with end blocks, test it, you'll like it). You can also create your own pylint plugin like we suggested three time already. I'm going to lock the issue now.