Versions:
Python: 3.10.4
Pylint: 2.15.3
Visual Studio Code: 1.72.2
The .pylintrc file was generated using
pylint --generate-rcfile
command.
It has the following option configured:
[METHOD_ARGS]
# List of qualified names (i.e., library.method) which require a timeout
# parameter e.g. 'requests.api.get,requests.api.post'
timeout-methods=requests.api.delete,requests.api.get,requests.api.head,requests.api.options,requests.api.patch,requests.api.post,requests.api.put,requests.api.request
However I see an error which sounds:
Unrecognized option found: timeout-methods Pylint(E0015:unrecognized-option)
The documentation states that option timeout-methods is supported: https://pylint.pycqa.org/en/latest/user_guide/configuration/all-options.html#timeout-methods.
So I am lost why do I have that error displayed by pylint in visual studio code.
As the comments under the original code showed, the pylint version bundled in the VS Code extension and the one that was used to generate the .pylintrc file differ.
Normally, the VS Code Pylint extension should use the pylint version installed in the Python environment that you configured to use for your project, and only falls back to the bundled version if no other pylint version was found. See also the extension docs for details.
Check the following:
Make sure that you configured the correct Python environment for your project. See Select a Python interpreter in the docs.
Make sure that you have installed pylint in the Python environment you have configured for your project, and are not accidentally using a pylint installation from your global Python environment. After configuring the Python interpreter (see step 1), once you open a new terminal in VS Code this environment should be activated by default. Run pip list | grep pylint (macOS/Linux) or pip list | findstr pylint (Windows) to check if pylint is installed.
If both 1 & 2 are fulfilled and you still have problems, check if pylint.importStrategy is maybe set to useBundled in your VS Code settings.json, and remove it or set it to fromEnvironment.
pylint 2.15 take this option into account correctly. But it was released only 2 month ago. Your error must come from the pylint version included in visual studio code that might lag a little behind and do not handle it yet.
Related
I have downloaded Pandas library with pip install pandas through the command prompt, when I try to import pandas as pd PyCharm returns an error : ModuleNotFoundError: No module named 'pandas'
I have tried to uninstall and install again many times but nothing seems to work. Does anybody know a solution to this?
You can try downloading the library from PyCharm settings:
File -> Settings
then, Project: -> Python Interpreter
Click a + sign to the right,
Search for the pandas library,
and finally, press 'Install Package'
I think you have to choose the right python interpreter. Check my screenshot
You likely have multiple copies of Python installed on your system. PyCharm can be configured to use any version of Python on your system, including any virtual environments you've defined. The solution is to match up the version of Python you've installed Pandas into with the version of Python that PyCharm is using to run your code.
There are two places where you specify a Python version. First of all, your Project has a version associated with it. Check the "Python Interpreter" section of the "Project" section of your Preferences for that. That version is used for syntax highlighting, code completion, etc.
By default, the abovementioned Python version will also be used to run your code. But you can change the version of Python that your code is run with by creating or modifying a Run Configuration. To do this, check the menu next to the Run and Debug toolbar buttons near the top-left of your PyCharm window.
When you do get into the Python Interpreter section of the Preferences, you'll find that you can see all of the modules installed for each Python version that PyCharm knows about. You can use this to check to see if Pandas is installed for a particular Python version.
I would suggest you get comfortable with all that I've said above. It will save you many headaches in the future.
I just updated my project to Python 3.7 and I'm seeing this error when I run mypy on the project: error: "Type[datetime]" has no attribute "fromisoformat"
datetime does have a function fromisoformat in Python 3.7, but not in previous versions of Python. Why is mypy reporting this error, and how can I get it to analyze Python 3.7 correctly?
Things I've tried so far:
Deleting .mypy_cache (which has a suspicious looking subfolder titled 3.6)
Reinstalling mypy with pip install --upgrade --force-reinstall mypy
To reproduce:
Create a python 3.6 project
install mypy 0.761 (latest) in the project venv
scan the project with mypy (mypy .)
update the project to python 3.7
add a file with this code in it:
from datetime import datetime
datetime.fromisoformat('2011-11-04 00:05:23.283')
scan the project again (mypy .) [UPDATE: this actually works fine. It was rerunning my precommit hooks without reinstalling pre-commit on the new Python version venv that was causing the problems.]
You are running mypy under an older version of Python. mypy defaults to the version of Python that is used to run it.
You have two options:
You can change the Python language version with the --python-version command-line option:
This flag will make mypy type check your code as if it were run under Python version X.Y. Without this option, mypy will default to using whatever version of Python is running mypy.
I'd put this in the project mypy configuration file; the equivalent of the command-line switch is named python_version; put it in the global [mypy] section:
[mypy]
python_version = 3.7
Install mypy into the virtualenv of your project, so that it uses the exact same Python version.
Note that if you see this issue (and didn't accidentally set --python-version, on the command-line or in a configuration file, you are certainly not running mypy from your project venv.
The solution was simple: simply run mypy with the --python-version flag. so in my case it was --python-version=3.7.
If you use pre-commit, you can also add this as an argument in a precommit check in your .pre-commit-config.yaml. Mine looks like this:
repos:
...
- repo: https://github.com/pre-commit/mirrors-mypy
rev: v0.750 # Use the sha / tag you want to point at
hooks:
- id: mypy
args: [--python-version=3.7]
If you run mypy often from the command line you can also add it to a config file as described herehttps://mypy.readthedocs.io/en/stable/config_file.html.
Another note: if mypy is reporting errors when your pre-commit hooks run, but not when it is run by itself from the project venv, then you need to either
add python-version as an argument like I do above, or
reinstall pre-commit in the new project venv (with the correct python version)
I am trying to install cx_Freeze==5.0.2 on Windows 8.1 / Python 3.7 but I am getting this Error:
I do not know what exactly cx_Freeze is for or why i need this version - it is from a requirements text file that threw and error, and this module is the only one that i could not install manually.
It says something about Visual C++ above, but I do have it installed, so I dont know why its saying that.
cx_Feeze needs compiling to run (this is usually done for you on Windows but it has not been done for 3.7 yet (see the releases on PyPi) so you have two options:
Wait until it is (shouldn't be more than a few days/weeks, it wasn't last time python updated in any case)
Compile it yourself
In the case of compiling, if you have VS installed then you probably have not set the correct environment variables
SET DISTUTILS_USE_SDK=1
SET MSSdk=1
Taken from here.
I would recomend the answers in this question over the duplicate suggested above.
This question already has answers here:
Dealing with multiple Python versions and PIP?
(28 answers)
Closed 5 years ago.
I've installed django using the pip command (pip install Django), but i can't run it using the py command, as it can't find the module.
I can only make it works using 'python' command.
Here is a summary of the screenshot I have atttached
$ python --version
Python 3.6.1
$ py --version
Python 3.6.0
It also looks like django works only with 3.6.1.
Is there any way to set both commands to run newest version of python?
Screenshot:
You're using Python launcher for Windows when you executepy. You could be specific about which Python interpreter version that you want py to execute with this command:
> py -3.6
See this section from PEP 397:
Python Version Qualifiers
If no version qualifiers are found in a command, the environment
variable PY_PYTHON can be set to specify the default version qualifier
- the default value is "2". Note this value could specify just a major version (e.g. "2") or a major.minor qualifier (e.g. "2.6"), or even
major.minor-32.
If no minor version qualifiers are found, the environment variable
PY_PYTHON{major} (where {major} is the current major version qualifier
as determined above) can be set to specify the full version. If no
such option is found, the launcher will enumerate the installed Python
versions and use the latest minor release found for the major version,
which is likely, although not guaranteed, to be the most recently
installed version in that family.
In addition to environment variables, the same settings can be
configured in the .INI file used by the launcher. The section in the
INI file is called [defaults] and the key name will be the same as the
environment variables without the leading PY_ prefix (and note that
the key names in the INI file are case insensitive.) The contents of
an environment variable will override things specified in the INI
file.
Plus Python launcher isn't just limited to launching different Python versions, it also parses shebang #! in source code files, providing a functionality similar to that in *nix operating systems in Windows.
*Refer to Python Launcher for Windows documentation.
On windows, py is an executable stored in the C:\Windows folder. I honestly don't know what it contains, as I am used to where it is a symbolic link on linux, and my windows install shows the normal python executable as being a fraction of the size of py, despite my being quite sure that they point to the same installation. Regardless, you can fix your problem by deleting or renaming (python.bak, etc) the executable you don't want to keep using from the Windows folder, then copying the one you want in place and renaming it to the same name that you previously deleted or renamed. I can't imagine this is the official way to fix this problem, but this will work. Also, in the future, feel free to specify the version you are installing to with pip explicitly if you want to be sure of which installation you are using instead of just running whatever points to pip:
py -m pip install packagename
python -m pip install packagename
Running into problems with multiple python versions on the same system is quite common with Windows, so setting up a virtual environment may be beneficial. This is explained in the Django Windows install how-to.
It is PythonQt : pythonqt.sourceforge.net. I am using PythonQt-1.1 . Qt version 4.6.2 and Python 2.6.4.10 . Visual studio 2008
From instruction:
cd PythonQtRoot
vcvars32
qmake
nmake
after I typed qmake, it generated makefile, then I entered nmake but it said "makefile(22) :fatal error U1000: syntax error: ')' missing in macro invocation Stop." What did I do wrong here?
Thanks in advance....
I remember running into similar problems when building other packages with recent releases of Qt on Win32. I'm running under cygwin, by the way. After a fair amount of debugging, I discovered that 'qmake' was using the wrong 'mkspec'. One thing that helped this situation was to force the use of the correct mkspec, like so:
export QMAKESPEC=win32-msvc2008
or
export QMAKESPEC=win32-msvc
To find the list of all valid mkspecs, I looked in the directory:
c:\Qt\4.6.0\mkspecs
or
c:\Qt\2010.01\qt\mkspecs
For one particular package, I had some conflicts with other tools installed on my system and had to edit the actual mkspec file to point to the correct tool using an absolute path, but it sounds like that is not your problem here. It sounds like yours is generating a gmake-compatible Makefile instead of an nmake-compatible Makefile, so this fix should work.
-- Glenn
My suggestion is to include the PythonQt project as part of your very same project with CMake.
You then simply have to build it as part of your project statically (remove the SHARED from the add_library in the base CMakeLists.txt, by remembering that if you want it to be so, you have to remove the project(PythonQt) from its base CMakeLists.txt and then adding to your proper CMakeLists.txt base file the following:
if( PYTHON_QT_SUPPORT )
message(STATUS ":::: Including support for PythonQT Shell ::::")
# Include Python directories
find_package(PythonLibs REQUIRED)
include_directories("${PYTHON_INCLUDE_DIR}")
# Include PythonQt
include_directories(YOURPATHTOPYTHONQT/pythonqt/src)
add_subdirectory(YOURPATHTOPYTHONQT/pythonqt)
endif(PYTHON_QT_SUPPORT)
Have you made sure to update the Python/Qt versions in the build folder, and include everything you need in your environment?
In build\python.prf:
update python version
Use a Visual Studio Command Prompt and skip the vcvars32.
set your environment paths:
set PATH=E:\toolkits\Trolltech\Qt-4.8.6\Win_x64_6.1_v12_debug\lib;%PATH%
set PATH=E:\toolkits\Trolltech\Qt-4.8.6\Win_x64_6.1_v12_debug\bin;%PATH%
set PYTHON_PATH=E:\toolkits\Python\2.7.9\Win_x64_6.1_v12
set PYTHON_LIB=E:\toolkits\Python\2.7.9\Win_x64_6.1_v12\libs
In those paths, you should have available:
all qt libraries (QtCore4.dll, etc.)
all qt executables (uic, moc, etc)
python26.dll, python.exe
I've also had to update the other .prf files to make sure the debug extensions are properly done when i'm binding on debug dlls.