Releases: DetachHead/basedpyright
v1.23.1 (pyright 1.1.391)
What's Changed
- fix
reportUnusedParameter
false positive on abstract setters by @DetachHead in #956 - fix semantic highlighting on names that are wrapped in parentheses across multiple lines by @DetachHead in #957
- update pyright to 1.1.391 by @DetachHead in #959
Full Changelog: v1.23.0...v1.23.1
v1.23.0 (pyright 1.1.390)
What's Changed
- fix duplicated semantic token for decorators which caused them to not get highlighted as decorators in neovim by @DetachHead in #925
- fix typeshed files sometimes being treated as source files which can lead to renames causing edits to be applied to typeshed files by @DetachHead in #932
- fix some typos in comments and documentation by @DetachHead in #936
reportUnusedFunction
on unused protected methods when the class is decorated with@final
by @DetachHead in #937- fix
reportUnsafeMultipleInheritance
false positive in diamond inheritance scenarios, which is safe due to how MRO works by @DetachHead in #940 - Add documentation for localization helper by @NCBM in #942
- fix paramspecs being printed as
Callable
types in inlay hints by @DetachHead in #943 - Add eglot configuration example to the website by @VictorCMiraldo in #935
- docs: fix typo by @kiyoon in #945
- docs: add missing
settings
table by @baggiponte in #950 - handle errors reading & writing the baseline file and report config / baseline errors more reliably by @DetachHead in #947
- officially support installing basedpyright via npm by @DetachHead in #953
New Contributors
- @VictorCMiraldo made their first contribution in #935
- @kiyoon made their first contribution in #945
- @baggiponte made their first contribution in #950
Full Changelog: v1.22.1...v1.23.0
v1.22.1 (pyright 1.1.390)
What's Changed
- fix incorrect inlay hints for generics where one of the types is a tuple by @DetachHead in #901
- fix readonly property member access highlighting the entire expression as readonly instead of just the member name by @DetachHead in #902
- Add installation instructions for Zed IDE by @JaagupAverin in #904 & #907
- fix false positive
reportUnnecessaryIsInstance
errors when narrowingCallable
whilestrictGenericNarrowing
is enabled by @DetachHead in #909 & #916 - add conda-forge package by @lucascolley in conda-forge/staged-recipes#28367 & #917
- fix potential performance issue caused by language server settings being re-loaded on every keystroke when doing inlay hints by @DetachHead in #922
- update upstream pyright version to 1.1.390 by @DetachHead in #926
New Contributors
- @JaagupAverin made their first contribution in #904
Full Changelog: v1.22.0...v1.22.1
v1.22.0 (pyright 1.1.389)
What's Changed
improved narrowing for generic types
when narrowing a type using an isinstance
check, there's no way for the type checker to narrow its type variables, so pyright just narrows them to "Unknown":
def foo(value: object):
if isinstance(value, list):
reveal_type(value) # list[Unknown]
this makes sense in cases where the generic is invariant and there's no other way to represent any of its possibilities. for example if it were to be narrowed to list[object]
, you wouldn't be able to assign list[int]
to it. however in cases where the generic is covariant, contravariant, or uses constraints, it can be narrowed more accurately.
this release introduces the new strictGenericNarrowing
setting to address this:
class Foo[T_co, T_contra]:
def foo(self, value: T_contra) -> T_co: ...
def foo(value: object):
if isinstance(value, Foo):
reveal_type(value) # previously `Foo[Any, Any]`, now `Foo[object, Never]`
for more information, see the docs.
huge thanks to @beauxq for the help on this. implemented in #745
new diagnostic rule - reportExplicitAny
similar to reportAny
, however this rule bans usages of the Any
type itself rather than expressions that are typed as Any
:
def foo(baz: Any) -> Any: # error: reportExplicitAny
print(baz) # error: reportAny
implemented in #83
other changes
- Chinese (Simplified) localization update (2024.11) by @NCBM in #879
- Fix duplicated
strictListInference
in the docs by @rbrgmn in #888 - show
Never
instead ofNoReturn
when it's inferred as the return type of a function by @peacewalker122 in #895 - document
Never
andNoReturn
by @DetachHead in #899
New Contributors
- @rbrgmn made their first contribution in #888
- @peacewalker122 made their first contribution in #895
Full Changelog: v1.21.1...v1.22.0
v1.21.1 (pyright 1.1.389)
What's Changed
- Update License Info with Well-known OSA MIT License Classifier by @macserv in #857
- fix crash when project contains a
package.json
with"type": "module"
by @DetachHead in #862 - fix unknown imports being incorrectly highlighted as a variable by @DetachHead in #863
- make properties with no setter highlighted as readonly in the semantic highlighter by @DetachHead in #864
- update upstream pyright version to 1.1.389 by @DetachHead in #872
New Contributors
Full Changelog: v1.21.0...v1.21.1
v1.21.0 (pyright 1.1.388)
What's Changed
new "hint"
diagnostic category
previously, in addition to the standard diagnostic categories "error"
and "warning"
, some diagnostic rules such as reportUnreachable
and reportDeprecated
supported special diagnostic categories like "unreachable"
and "deprecated"
respectively, which would show as a hint in your editor instead of an error:
the issue with these hints is that they only make sense for diagnostic rules that relate to unnecessary or deprecated code. but there was no way to set a hint-level diagnostic for other diagnostic rules. the configuration for these hints was also needlessly confusing (eg. "unreachable"
and "unused"
look exactly the same). they also didn't make sense for editors that don't support diagnostic tags.
this release introduces the new "hint"
diagnostic category to replace the "deprecated"
, "unused"
and "unreachable"
categories, which are now deprecated. for most rules, they will display as a hint:
but for rules where it makes sense to do so, the appropriate diagnostic tag (unnecessary or deprecated) will be applied automatically. this also allows all baselined diagnostics to be displayed as a hint, rather than just ones that can be considered unreachable/unnecessary.
for more information, see the docs
(implemented in #845)
other changes
- fix locale parsing on Linux by @arenekosreal in #834
- Fix file rename check running on files that aren't part of the workspace by @DetachHead in #843
- fix inlay hints appearing on
super()
calls by @DetachHead in #847 - update upstream pyright version to 1.1.388 by @DetachHead in #851
New Contributors
- @arenekosreal made their first contribution in #834
Full Changelog: v1.20.0...v1.21.0
v1.20.0 (pyright 1.1.387)
What's Changed
inlay hints for generics
these can be enabled using the new basedpyright.analysis.inlayHints.genericTypes
setting:
note that it's disabled by default because the information it provides is often redundant when basedpyright.analysis.inlayHints.variableTypes
is enabled:
new diagnostic rule: reportUnannotatedClassAttribute
pyright does not warn when a member of a class that doesn't have a type annotation is overridden with an incompatible type:
class A:
value = 1
class B(A):
value = None # no error, even though the type on the base class is `int` and the type here is `None`
this decision seems to have been made for performance reasons, which is fair enough. but because it's unsafe, there should be a check that enforces type annotations on class attributes (unless the class is decorated with @final
). the reportUnannotatedClassAttribute
rule will do just that:
class A:
value = 1 # error: Type annotation for attribute `value` is required because this class is not decorated with `@final`
(implemented in #812)
merge upstream & experimental inline TypedDict
update
- update upstream pyright version to 1.1.387 (#829)
- previously, we supported an experimental syntax for defining inline
TypedDict
s:this used to be supported in pyright but was removed a few months ago because it was never made into a PEP. i decided to keep the feature in basedpyright, however a draft PEP was created for it recently, which resulted in the feature being added back in this release of pyright, but with a different syntax:foo: dict[{"foo": int}] = {"foo": 1}
+ foo: TypedDict[{"foo": int}] = {"foo": 1}
- to reduce confusion, i've removed support for the old
dict[{"foo": int}]
syntax. from now on any deviations we make from the standard will be configured using a separate option instead of using pyright'senableExperimentalFeatures
setting, which is now disabled by default like it is in pyright (#831)
other changes
- fix crash when
pyproject.toml
contains an emoji by @DetachHead in #822 - fix import suggestion code actions not working when no workspace is open by @DetachHead in #824
- fix hang when installing basedpyright from github url using uv by @DetachHead in #825
- Chinese (Simplified) localization update (2024.10) by @NCBM in #767
- Remove redundant bullet point in docs by @tylerlaprade in #811
New Contributors
- @tylerlaprade made their first contribution in #811
Full Changelog: v1.19.1...v1.20.0
v1.19.1 (pyright 1.1.386)
What's Changed
- fix
typeCheckingMode
still defaulting to"all"
in the language server when there's no config file by @DetachHead in #791 - prevent inlay hints from appearing on enum members by @DetachHead in #793
- update upstream pyright version to 1.1.386 by @DetachHead in #805
- the new version of the toml parser included in this release was busted - see microsoft/pyright#9296 (and i think it also might have a memory leak on windows?), so i switched it to use js-toml instead
Full Changelog: v1.19.0...v1.19.1
v1.19.0 (pyright 1.1.385)
What's Changed
fixing the overly strict default typeCheckingMode
it may be an unpopular opinion, but i believe that type checkers/linters should be as strict as possible by default - to ensure that the user is made aware of all potential issues in their code, and that they are the ones responsible for making the conscious decision to reduce the strictness if they wish. i expand on my perspective in this comment.
the reality though is that it's really annoying for the user to see the same red line on both an unknown import and an unused import.
basedpyright 1.19.0 introduces a new default typeCheckingMode
called "recommended"
, which sets most of the stricter rules to be reported as a warning instead of an error. we've also added a new setting called failOnWarnings
for the CLI which is enabled by default in this mode.
i believe this addresses the concerns some users have had regarding the default settings, while still ensuring that the user is made aware of all the checks basedpyright has to offer.
you can read more about the diagnostic rulesets in the docs.
(implemented in #759)
other changes
- add new
reportImplicitAbstractClass
diagnostic rule by @DetachHead & @KotlinIsland in #774 - generate builtin docstrings for python 3.13 by @DetachHead in #768
- update documentation for editables to clarify that it's talking about build backends rather than frontends by @DetachHead in #770
- Add link to pylance issues to pylance features page by @xixixao in #777
- update upstream pyright version to 1.1.385 by @DetachHead in #782
New Contributors
Full Changelog: v1.18.4...v1.19.0
v1.18.4 (pyright 1.1.384)
What's Changed
language server
- add settings to disable each type of inlay hint by @DetachHead in #738, #740
- don't show inlay hints for positional arguments by @DetachHead in #741
- only show exact matches in import suggestion code actions by @DetachHead in #748
documentation
- Fix diagnostic rule documentation links on old versions of basedpyright by @DetachHead in #737
- various improvements and fixes to the docs by @DetachHead in #743
- fix broken links
- update some wording that implied the only way to run basedpyright in an IDE is by using the vscode extension
- add some editor-specific examples of how to configure the language server
other changes
- update upstream pyright version to 1.1.384 by @DetachHead in #758
Full Changelog: v1.18.3...v1.18.4