4 ms·

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. Inferri

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 8mo ago
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 8mo ago
  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 8mo ago
    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 8mo ago
      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 8mo ago
        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.

maleldil 8mo ago

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 8mo ago
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 8mo ago
  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 8mo ago
    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 8mo ago
      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.