I'm using VSCode for python and am getting a typing error with Pylance that appears incorrect and is not reported as an error by mypy --strict.
from openpyxl import load_workbook
wb = load_workbook("c:/temp/file.xlsx")
ws = wb["Sheet1"]
x = ws["A1"]
Pylance reports "__getitem__" method not defined on type "Chartsheet" for ws["A1"]. mypy reports Success: no issues found in 1 source file
How can I get Pylance to behave better, other than #type: ignore? Or should I just use mypy instead?
Related
In VSCode's settings.json, I enabled PyLance's type checking:
"python.analysis.typeCheckingMode": "basic"
This shows all typing issues as errors (underlined in red), even when code is valid Python and will run with no issue.
For example, the following code is valid Python, and works:
if 4 % 2 == 0:
a = 3
print(a)
...but PyLance shows an error because of the case where a is unbound:
I want to only mark as "errors" the actual syntax errors that will be rejected by Python, and mark everything else as warnings. I can do it for one category with:
"python.analysis.diagnosticSeverityOverrides": {
"reportGeneralTypeIssues": "warning"
}
How can I do that for all such errors?
Sorry, but I am afraid you only can override the diagnostic severity explicitly one by one.
Such as set "reportUnboundVariable": "warning", to change the error to warning which you have metioned in the above.
But, there is no way to change all of them one time.
I have the following simple code:
import winrt.windows.applicationmodel.datatransfer as DataTransfer
clipboard = DataTransfer.Clipboard
print(clipboard.clear())
And am getting this error, any idea how to fix?
print(clipboard.clear())
RuntimeError: CoInitialize has not been called.
Problem: VS Code is not underlining errors (with wavy red underlining) as it used to.
Problem exists for me and my friend (macOS and Windows)
Linter: mypy
settings.json:
{
"python.pythonPath": "/Users/username/.pyenv/versions/3.8.5/bin/python",
"python.linting.pylintEnabled": false,
"python.linting.mypyEnabled": true,
"python.linting.enabled": true
}
After running the script VS will underline found errors, but still wont underline any newly written errors.
When typing anything in the script, OUTPUT:python shows the following (or simular), which i dont understand and am not sure if its relevant:
Error 2020-11-09 20:20:07: stderr jediProxy Error (stderr) /Users/username/.vscode/extensions/ms-python.python-2020.10.332292344/pythonFiles/completion.py:584: DeprecationWarning: Deprecated since version 0.16.0. Use Script(...).get_names instead.
jedi.api.names(
Error 2020-11-09 20:20:27: stderr jediProxy Error (stderr) /Users/username/.vscode/extensions/ms-python.python-2020.10.332292344/pythonFiles/completion.py:592: DeprecationWarning: Providing the line is now done in the functions themselves like `Script(...).complete(line, column)`
script = jedi.Script(
/Users/username/.vscode/extensions/ms-python.python-2020.10.332292344/pythonFiles/completion.py:592: DeprecationWarning: Deprecated since version 0.17.0. Use the project API instead, which means Script(project=Project(dir, sys_path=sys_path)) instead.
script = jedi.Script(
Error 2020-11-09 20:20:27: stderr jediProxy Error (stderr) /Users/username/.vscode/extensions/ms-python.python-2020.10.332292344/pythonFiles/completion.py:105: DeprecationWarning: Deprecated since version 0.16.0. Use Script(...).get_signatures instead.
call_signatures = script.call_signatures()
/Users/username/.vscode/extensions/ms-python.python-2020.10.332292344/pythonFiles/completion.py:230: DeprecationWarning: Deprecated since version 0.16.0. Use Script(...).complete instead.
completions = script.completions()
Thanks for helping!
I recently had to reformat my computer, and now whenever I try to call the Sheet.api property in xlwings, I get the following result:
>>> wb = xw.Book('<path-to-wb>')
>>> sht = wb.sheets['Sheet1']
>>> sht.api
<win32com.gen_py.Microsoft Excel 16.0 Object Library._Worksheet instance at 0x1293314650312>
Previously, sht.api returned me a <xlwings._xlwindows.COMRetryObjectWrapper at 0x1e816dda7c8> object.
Is this some kind of windows configuration that I have to restore? Why is xlwings behaving differently all of a sudden?
This isn't all of a sudden but the effect of upgrading to a new version where the RetryObjectWrapper is printed with more meaningful information. It's still the same object though as you will see when you print its type:
>>> type(sht.api)
<class 'xlwings._xlwindows.COMRetryObjectWrapper'>
This code:
import os
from win32com.shell import shell, shellcon
tempFile = os.path.join(os.path.abspath(os.path.curdir), u'_tempfile.tmp')
# print tempFile
dest = os.path.join('C:\Program Files', '_tempfile.tmp')
with open(tempFile, 'wb'): pass # create the file
try: # to move it into C:\Program Files
result, aborted = shell.SHFileOperation(
(None, # parent window
shellcon.FO_MOVE, tempFile, dest,
# 0,
shellcon.FOF_SILENT, # replace this with 0 to get a UAC prompt
None, None))
print result, aborted
except: # no exception raised
import traceback
traceback.print_exc()
Prints 120 False - 120 being CallNotImplementedError. If the flags are set to 0 then you get a UAC prompt as expected. Now why is not the result 5 (AccessDeniedError) ? Is something not implemented indeed or is it a bug or what do I not get ?
Needless to say that this was hard to debug - I was expecting an access denied and I had to look very closely to see what was wrong.
You're misreading the error code. SHFileOperation uses its own set of error codes separate from the system error codes; in this case, 0x78/120 is:
DE_ACCESSDENIEDSRC: Security settings denied access to the source.
That doesn't seem like it's the likely error (the destination is the problem), but this function is deprecated (replaced in Vista by IFileOperation) and while it still exists in Vista+, they may not have been particularly careful about returning entirely accurate error codes for situations (like UAC) that didn't exist pre-Vista.
Per the docs:
These are pre-Win32 error codes and are no longer supported or defined in any public header file. To use them, you must either define them yourself or compare against the numerical value.
These error codes are subject to change and have historically done so.
These values are provided only as an aid in debugging. They should not be regarded as definitive.