3 ms·

0 can be inferred as a float too, so doesn’t it make sense to type numbers?

porridgeraisin 1y ago
I believe mypy infers i as an integer in i = 0. I remember I had to do i = 0.0 to make it accept i += someFloat later on. Or of course i:float = 0 but I preferred the former.
- hk__2 1y ago
  Yes, but not in arguments: def f(i=0) -> None: j = i + 1 k = 1 reveal_type(i) reveal_type(j) reveal_type(k) Output: Revealed type is "Any" Revealed type is "Any" Revealed type is "builtins.int"
  - jsjohnst 1y ago
    Because it shouldn’t in function arguments. The one defining the function should be responsible enough to know what input they want and actually properly type it. Assuming an int or number type here is wrong (it could be optional int for example).
    - hk__2 1y ago
      In TypeScript arguments with a default value "inherit" the type of that value, unless you explicitely mark it otherwise. I believe this is how Pyright works as well.
      - jsjohnst 1y ago
        But the type signature of: int -> int Is wrong. At minimum it’s: Optional[int] -> int Because you provided a default value so clearly it’s not required to provide an input parameter. It’s also wrong to assume `0` is an int. There’s other valid types it could be. If the default was say `42`, I’d be pushing back a little less (outside of the Optional part), but this contrived example from GP had 0, which is ambiguous on what the inferred typing must be.
hk__2 1y ago
Try: def f(i=0) -> None: reveal_type(i) The inferred type is not `float` nor `int`, but `Any`. Mypy will happily let you call `f("some string")`.
- veber-alex 1y ago
  That's a mypy issue. Pyright correctly deduces the type as int. In any case it's a bad example as function signatures should always be typed.
- jsjohnst 1y ago
  So you want strong typing, but then are to lazy to properly type your function definitions?
  - toolslive 1y ago
    no need to explicitly write the type if you have type inference: > # fun x -> x + 1;; > - : int -> int = <fun> >
    - jsjohnst 1y ago
      1) the code you wrote isn’t Python. 2) inferring the type is int isn’t guaranteed to be correct in this case
      - toolslive 1y ago
        I was merely giving an example that strong typing has nothing to do with having to write the types. (and, obviously, the inferred type (int -> int) is correct. )
        Izkata 1y ago
        Only if reveal_type only accepts an int. Just because the default value of i is 0 doesn't mean anything about what could be passed in.

I believe mypy infers i as an integer in i = 0. I remember I had to do i = 0.0 to make it accept i += someFloat later on. Or of course i:float = 0 but I preferred the former.

hk__2 1y ago
Yes, but not in arguments: def f(i=0) -> None: j = i + 1 k = 1 reveal_type(i) reveal_type(j) reveal_type(k) Output: Revealed type is "Any" Revealed type is "Any" Revealed type is "builtins.int"
- jsjohnst 1y ago
  Because it shouldn’t in function arguments. The one defining the function should be responsible enough to know what input they want and actually properly type it. Assuming an int or number type here is wrong (it could be optional int for example).
  - hk__2 1y ago
    In TypeScript arguments with a default value "inherit" the type of that value, unless you explicitely mark it otherwise. I believe this is how Pyright works as well.
    - jsjohnst 1y ago
      But the type signature of: int -> int Is wrong. At minimum it’s: Optional[int] -> int Because you provided a default value so clearly it’s not required to provide an input parameter. It’s also wrong to assume `0` is an int. There’s other valid types it could be. If the default was say `42`, I’d be pushing back a little less (outside of the Optional part), but this contrived example from GP had 0, which is ambiguous on what the inferred typing must be.

hk__2 1y ago

Try: def f(i=0) -> None: reveal_type(i) The inferred type is not `float` nor `int`, but `Any`. Mypy will happily let you call `f("some string")`.

veber-alex 1y ago
That's a mypy issue. Pyright correctly deduces the type as int. In any case it's a bad example as function signatures should always be typed.
jsjohnst 1y ago
So you want strong typing, but then are to lazy to properly type your function definitions?
- toolslive 1y ago
  no need to explicitly write the type if you have type inference: > # fun x -> x + 1;; > - : int -> int = <fun> >
  - jsjohnst 1y ago
    1) the code you wrote isn’t Python. 2) inferring the type is int isn’t guaranteed to be correct in this case
    - toolslive 1y ago
      I was merely giving an example that strong typing has nothing to do with having to write the types. (and, obviously, the inferred type (int -> int) is correct. )
      - Izkata 1y ago
        Only if reveal_type only accepts an int. Just because the default value of i is 0 doesn't mean anything about what could be passed in.