[drcongo]

It's also horrible for fasle positives unless your project happens to be the exact same setup as the maintainers' - I had to turn off the actual type checking on it. I've since moved wholesale to the Ty alpha and it feels a hell of a lot smarter.

[JimDabell]

It also inherits the unfortunate attitude of Pyright that it will warn against idiomatic Python (EAFP) in favour of non-idiomatic Python (LBYL):

https://github.com/microsoft/pyright/issues/1739

https://docs.python.org/3/glossary.html#term-EAFP

https://docs.python.org/3/glossary.html#term-LBYL

[maleldil]

Sometimes dynamic Python idioms are incompatible with typed Python. I personally think that's fine, since I consider static typing a significant improvement overall.

[JimDabell]

This isn’t. They actually fixed that bug. Then they changed their minds and backed the fix back out again because they don’t think you should write Python that way:

> I think EAFP is a very unfortunate and ill-advised practice.

They want you to not write the idiomatic Python:

    try:
        foo = bar["baz"]["qux"]
        ...
    except KeyError:
        ...

…and instead write the non-idiomatic version:

    if "baz" in bar and "qux" in bar["baz"]:
        foo = bar["baz"]["qux"]
        ...
    else:
        ...

If this were a linter then I would accept that it is going to be opinionated. But this is not a linter, it’s a type checker. Their opinions about EAFP are irrelevant. That’s idiomatic Python.

[IshKebab]

Well I agree with them. The second code is clearly better. Exceptions should be used for error handling and if those keys are actually optional then you should explicitly check if they exist (or use something like `bar.get("baz")`).

[JimDabell]

You are welcome to that opinion, but type checkers should not be opinionated, especially if they push people to write non-idiomatic Python. If you think this should be written a different way, that’s what lint rules are for.

[IshKebab]

Actually Python type checkers must be opinionated. Python doesn't define the semantics of type annotations so type checkers have to choose them.

They don't always choose the same options, so some Python code may type check in one type checker and not in another.

Yes this is a dumb situation but that's how it is. So Pyright has to make a choice here, and they chose the most sensible option.

You're free to disagree of course.

[kstrauser]

Eww, what? I hadn’t seen that before. Yikes, I hope the situation’s improved. I’d be butting into that continually.