[drumnerd]

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

[hk__2]

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")`.

[mzl]

How would a typing system know if the right type is `int` or `Optional[int]` or `Union[int, str]` or something else? The only right thing is to type the argument as `Any` in the absence of a type declaration.

[hk__2]

The typing system should use the most specific valid type, and the code author can broaden it with explicit typing if needed. No good typing system should ever infer a variable as `Any`: "I don’t know the type of this" (`unknown` in TypeScript) is not the same thing as "This function accepts anything". Conflating these things is one of the main reasons why Mypy is so annoying.

[mzl]

A typing system should only infer things that it knows are true, it should never invent restrictions. In a language like Python that is duck-typed, `Any` is the only reasonable choice in the absence of other real constraints like a type-annotation.

[rfoo]

`Any` is the correct call.

It could be:

  def f(i=0) -> None:
    if i is None:
      do_something()
    else:
      do_something_else()

Yeah, I know it's retarded. I don't expect high quality code in a code base missing type annotation like that. Assuming `i` is `int` or `float` just makes incrementally adoption of a type checker harder.

[hk__2]

No it’s not. The typing system should use the most specific type available, and it’s your responsability to broaden it if needed. That’s how it works in all statically-typed languages.

[veber-alex]

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]

So you want strong typing, but then are to lazy to properly type your function definitions?

[hk__2]

I want a typing system with a good inference that doesn’t require me to type each and every variable, just like in any good statically-typed language like OCaml or Typescript. Strong typing and explicit typing are two very different things.

[toolslive]

no need to explicitly write the type if you have type inference:

  > # fun x -> x + 1;;
  > - : int -> int = <fun>
  >

[jsjohnst]

1) the code you wrote isn’t Python.

2) inferring the type is int isn’t guaranteed to be correct in this case

[int_19h]

It's guaranteed to be correct if you use different operators for ints and floats, which is what at least some ML dialects (notably, OCaml) do precisely so that types can be inferred from usage.

That's the downside of operator overloading - since it relies on types to resolve, they need to be known and can't be inferred.

[toolslive]

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]

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.

[jsjohnst]

> and, obviously, the inferred type (int -> int) is correct.

No it’s not. It’s Optional[int] -> int at minimum. There are other completely valid signatures beyond that too.

[porridgeraisin]

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]

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]

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]

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]

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.