KotlinIsland

@jorenham We think that `In`/`Out` would be better - https://github.com/KotlinIsland/basedmypy/issues/466 Also see this series of discussions where I tried to argue the same thing: - https://github.com/python/peps/issues/2724 It also seemed that...

> But then how would you be able to explicitly mark a type type parameter as being invariant That would be the default: ```py class A[T]: ... # invariant ```...

> That would break backwards compatibility, since the (PEP 695) default is to automatically infer variance. Don't care about breaking backwards comparability, but for the 484 inclined, there would be...

> Breaking backwards backwards compatibility in basedpyright @DetachHead has different feelings about backwards-compatibility that I do. So he would probably have different ideas here for basedpyright. > but I was...

> ... so can I expect a basedpython fork / pre-compiler then? Yes. But because type annotations aren't generally evaluated at runtime, we can get away with a lot of...

even though pyright is working here, there is no inlay hint on the parameter

I think it is if you ever want to resolve it ```py type A = "int" type B = A | str resolve(B) ```

It wouldn't be possible to bring your own pyright, this project is setup such that it modifies a lot of source, not just acts as an 'expansion pack'.

Idea: allow multiple inheritance if the class doesn't define an `__init__`: ```py class A: def __init__(self, i: int): self.i = i # no error about missing `super().__init__()` class B: ......

Ah yes, `TypeIs` == basedmypy `x is T` Pep `TypeGuard` == basedmypy `x is T if True else False` They serve two different purposes and both are needed for different...