Skip to content

Releases: DetachHead/basedpyright

v1.23.1 (pyright 1.1.391)

18 Dec 09:10
Compare
Choose a tag to compare

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)

15 Dec 14:58
Compare
Choose a tag to compare

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

Full Changelog: v1.22.1...v1.23.0

v1.22.1 (pyright 1.1.390)

04 Dec 13:54
482dfe0
Compare
Choose a tag to compare

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 narrowing Callable while strictGenericNarrowing 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

Full Changelog: v1.22.0...v1.22.1

v1.22.0 (pyright 1.1.389)

23 Nov 11:49
Compare
Choose a tag to compare

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 of NoReturn when it's inferred as the return type of a function by @peacewalker122 in #895
  • document Never and NoReturn by @DetachHead in #899

New Contributors

Full Changelog: v1.21.1...v1.22.0

v1.21.1 (pyright 1.1.389)

13 Nov 11:07
Compare
Choose a tag to compare

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)

06 Nov 11:41
84fbb74
Compare
Choose a tag to compare

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:

image

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:

image

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

New Contributors

Full Changelog: v1.20.0...v1.21.0

v1.20.0 (pyright 1.1.387)

30 Oct 14:02
Compare
Choose a tag to compare

What's Changed

inlay hints for generics

these can be enabled using the new basedpyright.analysis.inlayHints.genericTypes setting:

  • when instantiating classes (#818)
  • Final and ClassVar annotations (#809)

note that it's disabled by default because the information it provides is often redundant when basedpyright.analysis.inlayHints.variableTypes is enabled:
image

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 TypedDicts:
    foo: dict[{"foo": int}] = {"foo": 1}
    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: 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's enableExperimentalFeatures 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

Full Changelog: v1.19.1...v1.20.0

v1.19.1 (pyright 1.1.386)

23 Oct 13:43
2024466
Compare
Choose a tag to compare

What's Changed

Full Changelog: v1.19.0...v1.19.1

v1.19.0 (pyright 1.1.385)

16 Oct 10:29
Compare
Choose a tag to compare

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)

09 Oct 10:32
3cc3341
Compare
Choose a tag to compare

What's Changed

language server

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

Full Changelog: v1.18.3...v1.18.4