I have loaded black and flake8 into a poetry virtual environment. I'd like to change the default line length in black or flake8 so they agree. What is the best way to do this?
Add a file .flake8 with the following :
[flake8]
max-line-length = 120
You can also do the same using a setup.cfg file.
You can use pyproject-flake8 , a monkey patching wrapper to connect flake8 with pyproject.toml configuration.
or use FlakeHeaven : This project is a fork of FlakeHell.
FlakeHell and other forks of it such as flakehell/flakehell are no
longer maintained and do not work with Flake8 4.0.x.
The short answer is add this to your pyproject.toml file (assuming you are using one since you are using poetry) and you should be good to go.
[flake8]
max-line-length = 88
extend-ignore = E203
This implies that the line length used by flake8 is set to 88, which is also the default used by black.
I would recommend that you take a look at the Line Length section of Black's README. The above snippet is taken from there. Black's authors also explain the rationale behind the choice of the default value. They also detail alternative options to make flake8 happy.
Related
I have written a try_pylint.py file to try if pylint can detect some incorrect style with Python 3.10.
"""This is a try for pylint detection.
"""
#hello world! --> missing a space, and it has only 1 (needs 2) blank line before it.
def print_hello():
"""print it
"""
print('hello')
If I run the command in terminal pylint try_pylint.py, it gives
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
However, if I use flake8, it can detect both of them.
flake8 try_pylint.py gives
try_pylint.py:4:1: E265 block comment should start with '# '
try_pylint.py:6:1: E302 expected 2 blank lines, found 1
Could you please show me how to configure pylint to detect them? By the way, I am using VS Code for developing Python code. It would be great if you can show me how to configure it on VS Code.
Thanks in advance!
The actual check is done by pycodestyle inside flake8. pylint do not check for this and for formatting in general (as black can format your code automatically, this kind of check are not very useful anymore).
You should use black, flake8 and pylint together, they are not mutually exclusive.
Just a note about comments handling in Pylint: there is a pylint checker that shows messages for empty comments in your code. The message/checker is called empty-comment.
I'm trying to run vimtutor on openSUSE Leap 15 1 on WSL2. I get the error E484: Can't open file /usr/share/vim/vim80/tutor/tutor.vim
When I run which vim (or which vimtutor) I get /usr/bin/vim (or /usr/bin/vimtutor) -- is the issue that I have multiple versions of vim installed and when I try vimtutor (which I understand to be a script) it can't access the correct one because of the way my PATH is configured? I've seen similar issues about this posted, but none that seem to deal with this specific issue as it applies to vimtutor.
The vim script is part of vim-data package.
If you looked at the spec file linked here,
https://build.opensuse.org/package/view_file/openSUSE:Factory/vim/vim.spec?expand=1
on line 567, the tutor.vim is split into the vim-data package.
It's part of the
%files data
block.
When running python scripts or programs built using python, errors are emitted in dark red. As I get older, this is getting harder for me to read, to the point I have to squint, magnify, or fuss with the console properties and re-run commands.
I really dont want to change the console defaults because other programs generally dont have this problem, and it just seems to be Python that doesn't honor the hosting console's color settings. I also dont know ahead of time which programs may have been built with python (Azure CLI for example) to set the colors ahead of time.
Is there a way to change the DarkRed that python wants to use for errors to a color that is easier to distinguish, like "regular" Red? For any py script or program that runs on my machine?
EDIT: Here is an example of invoking a program written using Python and the dark red. My py scripts library is on my work computer.
EDIT2: Its pip that was the other thing that uses the dark red.
First, python is innocent. The culprit is azure-cli itself. It uses a lib named knack for configuring logging. And knack uses colorama to configure colored output.
But the problem is, the RED in colorama is \033[31m. Which is what you see, somehow like dim red.
So the solution is simple, we manually modify that knack package.
Suppose your azure-cli is installed at C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2.
Then go to C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages, delete that knack directory or rename it.
Go to https://github.com/Microsoft/knack, download the package. add one line at line 47:
class _CustomStreamHandler(logging.StreamHandler):
COLOR_MAP = None
#classmethod
def get_color_wrapper(cls, level):
if not cls.COLOR_MAP:
import colorama
def _color_wrapper(color_marker):
def wrap_msg_with_color(msg):
return '{}{}{}'.format(color_marker, msg, colorama.Style.RESET_ALL)
return wrap_msg_with_color
colorama.Fore.RED = "\033[31;1m" # <- add this line
cls.COLOR_MAP = {
logging.CRITICAL: _color_wrapper(colorama.Fore.RED),
logging.ERROR: _color_wrapper(colorama.Fore.RED),
logging.WARNING: _color_wrapper(colorama.Fore.YELLOW),
logging.INFO: _color_wrapper(colorama.Fore.GREEN),
logging.DEBUG: _color_wrapper(colorama.Fore.CYAN)
}
return cls.COLOR_MAP.get(level, None)
...
Copy modifed package to corresponding location.
Test it again.
Bingbangba!
For pip specifically, there is a "--no-color" command line option:
https://pip.pypa.io/en/stable/reference/pip/#general-options
I have flake8-docstrings plugin installed and some others. But for some runs I want to ignore all the warnings of this plugin in some easy way: without creating a config file and without making a list of it's warning codes manually.
Is there any solution like:
flake8 . --ignore=Dxxx
or
flake8 . --disable-plugin=docstrings
?
You're almost there
flake8 --extend-ignore=D .
Will ignore all violations reported that start with D and flake8-docstrings is the only plugin that reports codes starting with D.
If you have suggestions on how to improve this section of documentation that describes how to do it, please open an issue.
I have an escript file which runs fine from the command line, i.e.:
./escript_file
It is meant to be cron friendly and all paths are explicit but when I run it, it fails to compile saying that there are bad attributes.
The bad attributes in question are macro definitions:
-define(COOKIE, 'somecookie').
The Answer
Thanks to Geoff Ready's suggestion I investigated which version of Erlang was running by printing out init:script_id() which prints out a string like {"OPT APN 181 O1", "R13B"} and, sure enough the command line and cron versions were picking up different versions.
The script had an initial line:
#!/usr/bin/env escript
and the operating system was 'finding' Erlang for me. The different environment variables of cron meant that a different erlang was being picked up (Geoff's first answer, and one I kinda knew but couldn't see how it would affect things).
The solution is then to force the version with a starting line of:
#!/usr/local/lib/erlang/erts-5.7.3/bin/escript
Postscript
There was also a different Ubuntu apt-get install of an earlier version of Erlang (in a different location to the source install) and an errant 64-bit install...
The cron environment just kept falling back to older and more obscure installs, failing all the while :(
Perhaps cron is picking up a different version of erlang in the path. Erlang R12B documentation says that escript ignores preprocessor directives besides include_lib. Erlang R13B documentation says that the preprocessor is run on the file. That would definitely explain the difference in behavior.
If it is working fine from the command line, a likely cause is a difference in environment variables for your interactive shell versus when cron runs the script.
Changing #!/usr/bin/env escript to #!/usr/local/bin/escript at the top of the file will work if the Erlang versions are the same.