pyright 1.1.349

Published 1.1.349

on Node.js NPM

Bug Fixes:

• Fixed default for reportImplicitStringConcatenation in schema file.
• Fixed a bug that resulted in an incorrect type evaluation for a union type used as a runtime expression. The type should be UnionType, not type[UnionType].
• Fixed regression that resulted in a false positive error when calling an abstract method on an abstract class that passes through the constraint solver (e.g. a generic decorator).
• Fixed a bug that results in a false positive when using a TypeVarTuple to capture the parameters of a generic callable that includes one or more default argument values.
• Fixed bug in tuple type compatibility logic that resulted in a false negative when dest type includes an upacked unbounded tuple plus additional entries.
• Fixed bug in tuple type compatibility logic that resulted in a false positive when dest type is tuple[Any, ...].
• Fixed a bug that results in a false negative when the literal typing.Any is passed to a function that accepts a type[T]. Any is a special form and should not be compatible with type.
• Fixed bug that resulted in incorrect type evaluation when a TypeAliasType is used in a value expression.
• Fixed a bug that resulted in incorrect type evaluation when calling a tuple constructor with bidirectional type inference and the value passed to the constructor is an Iterable[Any].
• Fixed a bug that resulted in incorrect type narrowing for sequence patterns when the subject expression contains a tuple with an unbounded component.

Behavior Changes:

• Removed name consistency match for functional form of Enum. After a discussion in the typing community, it was decided that name consistency checks in some cases were unnecessary and inappropriate for type checkers.
• Changed the way pyright translates tuple[()] into a specialized Sequence. It used to translate it to Sequence[Any], but the typing spec now clarifies that it should be Sequence[Never].
• Changed handling of tuple with multiple unpacked embedded tuples. Type spec now clarifies this is OK as long as there are not multiple unbounded embedded tuples.
• Added special-case logic to handle __name__ and a few other instance variables defined in the type class so they are treated specially when accessed from a class instance.

Enhancements:

• Added check for inappropriate use of Final in a value expression.
• Added support for enum member aliases defined within an enum class.
• Improved error messages for tuple type mismatches that involve tuples with indeterminate types.
• Added check for the use of Annotated or a type alias defined with Annotated as the second argument to an isinstance or issubclass call. This produces an exception at runtime.
• Added additional performance enhancements specifically for large unions of literal types.