Define linter tools to ensure minimum code quality for python.org website codebase

[luzfcb]

Is your feature request related to a problem? Please describe.

As the Python.org website is an open source project and a project open to external contributions, it is necessary for long-term maintenance and to lessen the workload of the maintainers to define what the project expects in terms of minimum code quality and perhaps also in terms of code style, thus making it easier for potential external contributors to contribute to the project.

The Python ecosystem has many tools that can analyze, suggest fixes, and automatically apply fixes to many of the common programming and code styling errors.

Making it as simple as possible to contribute to running the linter test suite and applying fixes is also an important factor in facilitating code contribution and review.

Describe the solution you'd like

My proposal is to add the below list of lint and fixers tools:

1. Centralize the execution of lint tools and apply fixes tools via pre-commit and ensure that all codebase is analyzed via GitHub actions. This makes contribution easier because pre-commit can keep separate virtualenvs for the tools, keep them isolated and up-to-date as per the pre-commit configuration file. Furthermore, it allows you to easily run all the tools simply by running the pre-commit command.
2. pyupgrade - A tool used to ensure that only python3.9+ compatible code is included in the codebase. It can also help a lot when we need to update the Python interpreter version.
3. bandit - A tool used to detect common security issues in Python code and thus prevent common errors from being included in our codebase.
4. flake8 - A tool to ensure a minimum code style and also warn about common errors
5. flake8-bugbear - A tool to check for additional errors not covered by the standard flake8 checks
6. Some of fixers of pre-commit-hooks -
   6.1 fix-byte-order-marker - removes UTF-8 byte order marker
   6.2 check-case-conflict - Check for files with names that would conflict on a case-insensitive filesystem like MacOS HFS+ or Windows FAT.
   6.3 check-merge-conflict - Check for files that contain merge conflict strings.
   6.4 check-symlinks - Checks for symlinks which do not point to anything.
   6.5 debug-statements - Check for debugger imports and py37+ breakpoint() calls in python source.
   6.6 detect-private-key - Checks for the existence of private keys.
   6.7 mixed-line-ending - Replaces or checks mixed line ending.
   6.8 end-of-file-fixer - Makes sure files end in a newline and only a newline.
   6.9 double-quote-string-fixer - This hook replaces double quoted strings with single quoted strings, but keet when the double quoted string contains a single quotes. This ensures that the codebase maintains compatibility with the Python interpreter's default behavior regarding the visual representation of strings.
   6.10 no-commit-to-branch - Used to avoid committing directly in specific branches like the main branch. This helps encourage the use of branches and helps prevent the contributor from making changes to the protected branch and end up having too many git conflicts when creating/rebasing a pull-request
7. isort - Ensure ordering and a style on the python imports
8. django-upgrade - A tool used to ensure that the codebase is compatible with a specific version of Django Framework. Also helps a lot when we need to upgrade a major version of Django.
9. editorconfig - It helps to define the standard expected by the project regarding the file encoding standard, the character used for indentation, number of characters used for indentation, and end-of-line character. This will ensure that your preferred editor will automatically use that setting. Note: You may still need to install a plugin in your editor. Pycharm comes preconfigured with editorconfig support, while VS Code is required to install the plugin manually.

Probably someone will suggest black. I don't like parts of the style of code generated by black, mainly because code that was purposely implemented in multiple lines in order to make it easier to use git diff in the future can be converted to single line code, which makes investigating changes via diff and git history much more complicated that should be. Since black is extremely opinionated and most rules are mandatory and cannot be configured, I like to avoid black whenever I can in my projects. I think it's up to the project to decide what's good for the project and what's not.
That said, in case the maintainers want black to be set, then I can include it in the list above;

If the maintainers agree with the proposal or part of the proposal, I commit to implementing them in the next few weeks in separate pull requests.

[ned-deily]

Thank you for your suggestion. However, this issue tracker is for issues with the Python.org website itself. Issues affecting the cpython code base and development process should be reported on the cpython issue tracker (https://github.com/python/cpython/issues).

[luzfcb]

@ned-deily I think there was a misunderstanding.

yes, I know this repository is for the Python.org website. My proposal is for the Python.org website codebase (which is made using Django framework) and not cpython.

Would it be possible to reopen the issue, since it is still pertinent to the Python.org website project, and not is a suggestion for the cpython project?

[ned-deily]

Sorry for the misunderstanding and thanks for clarifying the issue title!

[hugovk]

See #2539 and #2540 which will format with Ruff and take care of some of these.