[veber-alex]

It's not "mildly annoying".

I don't enable strict mode on multiple projects because people don't want to type anything outside of function signatures.

Inferring the type from the first use is 100% the correct choice because this is what users want 99% of the time, for the rest you can provide type information.

[maleldil]

Annotating empty collections is one of the few places you need to annotate outside function signatures. It's not a big deal. It doesn't happen that often.

[nomel]

And, when it does, you can just put them when the empty container is assigned:

    things: set[tuple[str, str, int]] = set()
    users: list[User] = []

Many people don't seem to know this exists.

[maleldil]

Yes, that's what I was referring to. I get it that Pyrefly wanted to advertise their approach here, but it's weird that they didn't at least acknowledge this. It's what I use because it works on every type check, and I don't need to rely on their particular implementation for this.

In fact, I recently migrated a project from Pyright to Pyrefly for performance reasons, and there was very little I had to change between. The most annoying thing was Pyrefly's lack of exhaustive pattern matching for StrEnum and Literal[...]

[ocamoss]

It's acknowledged at the end of the "infer any" strategy, but perhaps worded poorly.

> To improve type safety in these situations, type checkers that infer Any for empty containers can choose to generate extra type errors that warn the user about the insertion of an Any type. While this can reduce false negatives, it burdens developers by forcing them to explicitly annotate every empty container in order to silence the warnings.

ie: "type checkers that don't infer container types can emit an error and require users to annotate"

[maleldil]

I missed that. At least pyright will only emit an error if `typeCheckingMode` is strict (which forbids `Unknown`). It will happily treat `Unknown` as `Any` in basic mode.