python and pylance are throwing errors after vs code update #6373
Comments
|
Thanks for the issue, do you have an example that causes the problem? |
|
Not sure if it's related, but I starting seeing errors like |
I would hazard a guess that your new errors are a result of better typechecking in Pyright. Of course, a code example would let us know for sure. |
|
Also possibly related, I have type checking mode set to "off" yet I'm still seeing type errors: |
We're also seeing an increase in errors even though we left |
@keunhong do you have an example? The only errors you should get is syntax errors, although there's another change that might be the cause of this. Pyright recently changed such that if there's a pyrightconfig.json or a pyproject.toml with a tool.pyright section, its settings trump any settings in your settings.json. You can read this for more information if that's the case: |
rchiodo
added
the
settings-override
|
Thank you @rchiodo ! I am in the same boat here with the updated pylance/pyright spewing all kinds of type checking issues, lots of within pandas! Anyway, for others that have a |
Hey @rchiodo: Sure I can send a code chunk that was not working, and there were no indentation issues what so ever. what's the best way for me to send it to you? |
github-actions
bot
added
user responded
I assume you can't just paste it in the issue. You can also email me. It's my user id at microsoft dot com. |
from gql import gql, Client
from gql.transport.requests import RequestsHTTPTransport
from copy import deepcopy
from Utils.environment import get_azure_secret
from Utils.decorators.decorators import rename_columns_decorator
from Models._external.stack_adapt import lookup_client_id, campaign_group_dimensions, campaign_dimensions, ads_dimensions, campaign_facts
from Utils.developer.data_exploration import flatten_dict
from gql import gql, Client
from gql.transport.requests import RequestsHTTPTransport
import json
class Connector:
def __init__(self, client):
self._client = lookup_client_id(client)
self.advertiser_id = self._client
self.url = "https://api.stackadapt.com/graphql"
self.token = get_azure_secret('StackAdaptToken')
self.headers = {
'Authorization': f'Bearer {self.token}'
}
self.transport = RequestsHTTPTransport(url=self.url, headers=self.headers)
self.client = Client(transport=self.transport, fetch_schema_from_transport=True)
def execute_query(self, query, variables=None):
result = self.client.execute(query, variable_values=variables)
return resultso when I was trying to see where the error is occurring , up until this chunk above I got no errors. def _map_results_to_schema(self, result, schema):
"""Maps results from Snapchat API to a schema
Args:
result (dict): Result from Snapchat API
schema (dict): Schema to map results to
Returns:
row (dict): Row mapped to schema
"""
row = deepcopy(schema)
for k,v in result.items():
row[k] = result[k]
return rowand everything else. this is just a small code chunk. what was weird is that none of the code changed and when I would run as a python file the code would execute properly. This is one connector we have a bunch and all of them were returning the same error. |
|
Your second chunk has a tab in it, that's causing the indentation error. Can see it here (I turned on showing whitespace in VS code)
Not sure why we can't parse a tab though. Seems like it should be fine. Maybe there's a new bug introduced in the Pyright parser. |
|
Actually, it seems this is on purpose. The parser verifies tabs and spaces are consistent. This is by design. Has been for a while. |
|
This error was introduced 8 months ago, so it isn't something new in 2024.9.1. |
|
Can someone create a self-contained minimal repro? The Python parser does support mixing tabs and spaces even though this isn't recommended. The pyright parser is designed to mirror the behavior of the Python parser. Here is the documentation for how the Python parser treats tabs. If there are cases where pyright's behavior doesn't match that of the Python parser, that's something we should look at. |
|
Yeah, that repro doesn't run for me even with removing all the imports I don't have. I get the same indentation error that the Pylance parser produces. I changed it to this: class TestIndentation:
def __init__(self):
print('Created class')
def func_two(self):
print('Function two')
return 4
def call_func_two(self):
print('Calling Function two')
return self.func_two()
def func_three(self):
print('Function three')
return 5
x = TestIndentation()
x.call_func_two()Running that gives the same error that Pylance/Pyright produces: |
|
we're experiencing this issue too. with [tool.pyright]this code def say(s: str):
s.hi()produces a either adding downgrading to 2024.8.2 also works |
I think the tab was due to the way I copy pasted it into the comment. I think the issue might be related to VS code update as well. Did the settings of typeCheckingMode = "off" to pyproject.toml or removing the [tool.pyright] change from last months vs code to this months vs code? |
|
What exactly is the error you're getting @RBnzr? Can you share a screenshot? |
|
Oh and settings changes are entirely related to the Pylance extension. VS code update didn't have any impact on them. |
After looking at my own config indeed this is what's causing issue for us. This change has effectively changed the default of pyright (to mean pylance's typeCheckingMode) from disabled to enabled for anyone who has any pyright config (whether This is a significant regression for us and has led to us being forced to disable pyright for all of our Consider our scenario:
However, with this pylance 2024.9.1 update, because pyright's default Our (hopefully temporary) workaround is to set I hope this change can be reverted, or a workaround to address the use-case be shared. Thanks for your work on this!
The commit that introduced this change is microsoft/pyright@2aa9bf4c2 |
|
Here's where this changed in Pyright: |
|
@Hnasar, can you provide more information about your use case? In particular, who are "our users" in this context? Are you a library maintainer, and "our users" are consumers of your library? I ask because the I'm also curious why you previously added an empty The reason we made this change was to support projects that use pyright for type checking. Previously, contributors to a project were seeing inconsistent type checking behaviors between their pyright command line tool and their editor because some members of the team were (unintentionally) overriding type checker configuration in their language server settings. The new behavior is deterministic in that pyright type checking settings in a config file always take precedence over language server settings. |
By 'users' I mean to say 'team members who contribute to our repository' (I help maintain the linter config for a large repository). We have a
I can see the benefit of deterministic configs between CLI and editor. One way to resolve this issue is by setting a project's workspace settings accordingly. For example, if a project wants to enforce a particular level of checks, vscode's settings precedence has workspace settings with a higher precedence than user settings: so if there is a "python.analysis.typeCheckingMode": "standard",then there's no way for team members to unintentionally override the config. Separately, I can envision this change causing other issues; for example, if most of a codebase adheres to Perhaps pylance should use the pyright config as a lower bound, but allow users to opt-in to a higher level of checks? Basically my user story is — As someone who maintains a baseline shared config for a number of team members, I want to have checked-in config for pright/pylance that by default hides errors in the editor, but provides a way for users to opt-in to stricter checks without having to resort to a bunch of different copies of the pyright config. Said differently, I want to decouple the project config from the user config. |
|
@Hnasar, thanks for the additional details about your use case. Very helpful. Your usage of Am I correct in assuming that your team's If that approach doesn't work, another option is to set I see a couple of issues with your proposal to use the pyright config as a lower bound. First, composition of settings is more complex than that. The It sounds like you are not concerned about members of your team seeing divergent type analysis behaviors. That contradicts feedback that we've received from other pylance / pyright users, so we'll need to think about whether (and how) to reconcile this contradictory feedback. One more question, if you don't mind me asking. I'm curious why your team is using mypy for type checking rather than pyright. Maintaining support for two different type checkers can be costly. Mypy is known to have a lot of idiosyncrasies, bugs, and non-conformance with the Python typing spec. Is there something that keeps you from switching to pyright for type checking? If you did this, it would eliminate issues with configuration because you'd be using the same config for your editor and CI. |
|
our situation is the exact same as hnasar's! we primarily use mypy but some users want to turn on pyright. we put some settings in
my example of an empty section was just to repro the problem. our actual section has some configs to reduce typechecking errors
determinism is desirable, but the precedence seems backwards here. the editor uses the language server, which picks whether or not to use pyright. with this change, now the pyright config affects the editor, even though pyright doesn't know anything about it
that's what we plan to do next (though we put our settings in a code-workspace because, annoyingly, folder configs override all other configs, so there's no way for users to override configs if we check in this precedence really seems odd. we configure black, ruff, mypy, pylint, flake8 and non-python tools (eslint, tsc, etc.) globally and then the editor picks up the settings and layers any editor-specific changes on top. we can turn off black formatting in vsc and turn on ruff formatting without deleting the black config; we can turn off flake8 in vsc and use ruff lint without removing the flake8 config; but the only way to turn off pyright in vsc is to remove the pyright config |
|
(+1 to @raylu's perspective, moving settings into the language server makes it harder to use a shared config for pyright in other scenarios, and I like the comparison with other tooling configs.)
I didn't realize that there was a difference between pylance's configuration and pyright's configuration. My assumption (before this issue) is that they're equivalent. I see now that most of the settings that we have in
With our company workflow, we have a multi-language large monorepo (millions of lines) with teams working on isolated projects. Each team works on a small subset of the repository, and has control over the static analysis tooling for their subdirectory. Some teams wish only to use pylint; others use mypy, etc. Recently some teams have expressed interest in pyright. Because of this, I'm not concerned about team members seeing different type analysis behaviors. As a baseline, team members don't see pylance analysis errors. Some team members who wish to opt-in to pylance analysis are happy to have the extra checks and don't mind the false positives. (Another minor point I'm considering: we have a handful of team members who use neovim, with coc-pyright as a language server, and this tool also honors
As for why we use pyright's We explored using pyright's
The major blocker to using pyright is a longstanding heavy reliance on attrs. Though I'm personally very appreciative of PEP 681, we have several thousand non-dataclass-transform usages of attrs features (things like Click for off-topic pyright idiosyncrasyI can file some issues for the false positives once I investigate them a bit more, e.g. I see for a number of function calls into third party code, pyright seems to be getting confused about the origin of certain classes, and issuing false positives. |
Hey @rchiodo sorry I was away from my desk. Note that each error says line 1, this was the whole python class when running the full code chunk(more errors like below), and I tried it with another Class and it was giving the same error per line. perhaps the issue might only be affecting classes? ```shell
class CustomConnector: ... def init(self, client): ... self._client = lookup_client_id(client) ... self.advertiser_id = self._client ...
... self.url = "https://api.Custom.com/graphql" ... self.token = get_azure_secret('CustomToken') ... self.headers = { ... 'Authorization': f'Bearer {self.token}' ... } ... ... self.transport = RequestsHTTPTransport(url=self.url, headers=self.headers) ... self.client = Client(transport=self.transport, fetch_schema_from_transport=True) ... def execute_query(self, query, variables=None): File "<stdin>", line 1 def execute_query(self, query, variables=None): IndentationError: unexpected indent result = self.client.execute(query, variable_values=variables) File "<stdin>", line 1 result = self.client.execute(query, variable_values=variables) IndentationError: unexpected indent return result File "<stdin>", line 1 return result IndentationError: unexpected indent
File "<stdin>", line 1 def _map_results_to_schema(self, result, schema): IndentationError: unexpected indent """Maps results from Snapchat API to a schema File "<stdin>", line 1 """Maps results from Snapchat API to a schema IndentationError: unexpected indent
File "<stdin>", line 1 Args: IndentationError: unexpected indent result (dict): Result from Snapchat API File "<stdin>", line 1 result (dict): Result from Snapchat API IndentationError: unexpected indent schema (dict): Schema to map results to File "<stdin>", line 1 schema (dict): Schema to map results to IndentationError: unexpected indent
File "<stdin>", line 1 Returns: IndentationError: unexpected indent row (dict): Row mapped to schema File "<stdin>", line 1 row (dict): Row mapped to schema IndentationError: unexpected indent """ File "<stdin>", line 1 """ IndentationError: unexpected indent row = deepcopy(schema) File "<stdin>", line 1 row = deepcopy(schema) IndentationError: unexpected indent for k,v in result.items(): File "<stdin>", line 1 for k,v in result.items(): IndentationError: unexpected indent row[k] = result[k] File "<stdin>", line 1 row[k] = result[k] IndentationError: unexpected indent return row File "<stdin>", line 1 return row IndentationError: unexpected indent |
|
Sorry I'm not following. Is that the output from the runtime? Pylance isn't involved when running? |
|
@rchiodo Those are the errors I get when running the code. |
|
That should be a bug in your code, not Pylance or VS code. Updates to VS code or Pylance wouldn't affect the Python runtime. Unless there's some weird spacing problem? Maybe VS code is auto formatting with tabs? |
|
@rchiodo |
|
You can zip the code and e-mail it to me. My email is my github id at microsoft dot com. |
Type: Bug
keep getting unexpected indent error
Extension version: 2024.9.1
VS Code version: Code 1.92.2 (fee1edb8d6d72a0ddff41e5f71a671c23ed924b9, 2024-08-14T17:29:30.058Z)
OS version: Windows_NT x64 10.0.19045
Modes:
System Info
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled
webnn: disabled_off
A/B Experiments
The text was updated successfully, but these errors were encountered: