3 ms·

As the top comment says, if you don't know or want to define the type just use Any. That's what it's there for. That entire Reddit post is a clueless expert be

by mjr00 1y ago

As the top comment says, if you don't know or want to define the type just use Any. That's what it's there for. That entire Reddit post is a clueless expert beginner rant about something they don't really understand, unfortunate that it's survived as long as it has or that anyone is taking it as any sort of authoritative argument just because it's long.

pdonis 1y ago
> if you don't know or want to define the type That's not the issue the reddit post is raising. The reddit post is pointing out that what a "type" is is not as simple as it looks. Particularly in a language like Python where user-defined types proliferate, and can add dunder methods that affect statements that involve built-in operations. "Just use Any" doesn't solve any of those problems. > just use Any. All the above said: not putting a type in at all is even easier than using Any, and is semantically equivalent.
- mjr00 1y ago
  The Reddit post falls under the case of "don't know" the type. If you want to allow users to pass in any objects, try to add and fail at runtime... that's exactly what Any is for. But the entire post is built upon the premise that accepting all types is good API design. Which it isn't, at all.
  - zahlman 1y ago
    > But the entire post is built upon the premise that accepting all types is good API design. Which it isn't, at all. Was Tim Peters also wrong way back in the day when he counseled Guido van Rossum to allow floats to be added to integers without a cast, like other popular languages?
    - mjr00 1y ago
      How is `float | int` anywhere close to equivalent to `Any`?
      - MrJohz 1y ago
        How is "responds to the `__add__` method" anywhere close to equivalent to `Any`?
        mjr00 1y ago
        If your implication is that "implementing __add__ means you can use the + operator", you are incorrect. This is a common Python beginner mistake, but it isn't really a Python type checking issue, this is complexity with Python built-ins and how they interact with magic methods. My suggestion -- don't rely on magic methods.
        jampekka 1y ago
        > My suggestion -- don't rely on magic methods. So no e.g. numpy or torch then?
        MrJohz 1y ago
        I guess that's the difference between the Python and the TypeScript approach here. In general, if something is possible, valid, and idiomatic in JavaScript, then TypeScript attempts to model it in the type system. That's how you get things like conditional types and mapped types that allow the type system to validate quite complex patterns. That makes the type system more complex, but it means that it's possible to use existing JavaScript patterns and code. TypeScript is quite deliberately not a new language, but a way of describing the implicit types used in JavaScript. Tools like `any` are therefore an absolute last resort, and you want to avoid it wherever possible. When I've used Python's type checkers, I have more the feeling that the goal is to create a new, typed subset of the language, that is less capable but also easier to apply types to. Then anything that falls outside that subset gets `Any` applied to it and that's good enough. The problem I find with that is that `Any` is incredibly infective - as soon as it shows up somewhere in a program, it's very difficult to prevent it from leaking all over the place, meaning you're often back in the same place you were before you added types, but now with the added nuisance of a bunch of types as documentation that you can't trust.
        zahlman 1y ago
  - pdonis 1y ago
    > The Reddit post falls under the case of "don't know" the type. No, it doesn't. The desired type is known; it's "Addable" (i.e., "doesn't throw an exception when the built-in add operator is used"). The problem is expressing that in Python's type notation in a way that catches all edge cases. > If you want to allow users to pass in any objects, try to add and fail at runtime Which is not what the post author wants to do. They want to find a way to use Python's type notation to catch those errors with the type checker, so they don't happen at runtime. > the entire post is built upon the premise that accepting all types is good API design It is based on no such thing. I don't know where you're getting that from.
    - mjr00 1y ago
      > The desired type is known; it's "Addable" (i.e., "doesn't throw an exception when the built-in add operator is used"). The mistake both you and the reddit posts' author make is treating the `+` operator the same as you would an interface method. Despite Python having __add__/__radd__ methods, this isn't true, nor is it true in many other programming languages. For example, Go doesn't have a way to express "can use the + operator" at all, and "can use comparison operators" is defined as an explicit union between built-in types.[0] In C# you could only do this as of .NET 7, which was released in Nov 2022[1] -- was the C# type system unusable for the 17 years prior, when it didn't support this scenario? If this were any operation on `a` and `b` other than a built-in operator, such as `a.foo(b)`, it would be trivial to define a Protocol (which the author does in Step 4) and have everything work as expected. It's only because of misunderstanding of basic Python that the author continues to struggle for another 1000 words before concluding that type checking is bad. It's an extremely cherry-picked and unrealistic scenario either from someone who is clueless, or knows what they're doing and is intentionally being malicious in order to engagement bait.[2] This isn't to say Python (or Go, or C#) has the best type system, and it certainly lacks compared to Rust which is a very valid complaint, but "I can't express 'type which supports the '+' operator'" is an insanely esoteric and unusual case, unsupported in many languages, that it's disingenuous to use it as an excuse for why people shouldn't bother with type hinting at all. [0] https://pkg.go.dev/cmp#Ordered https://pkg.go.dev/cmp#Ordered [1] https://learn.microsoft.com/en-us/dotnet/standard/generics/math https://learn.microsoft.com/en-us/dotnet/standard/generics/m... [2] actually reading through the reddit comments, the author specifically says they were engagement baiting so... I guess they had enough Python knowledge to trick people into thinking type hinting was bad, fair enough!

by mjr00 1y ago

pdonis 1y ago

> if you don't know or want to define the type That's not the issue the reddit post is raising. The reddit post is pointing out that what a "type" is is not as simple as it looks. Particularly in a language like Python where user-defined types proliferate, and can add dunder methods that affect statements that involve built-in operations. "Just use Any" doesn't solve any of those problems. > just use Any. All the above said: not putting a type in at all is even easier than using Any, and is semantically equivalent.

mjr00 1y ago
The Reddit post falls under the case of "don't know" the type. If you want to allow users to pass in any objects, try to add and fail at runtime... that's exactly what Any is for. But the entire post is built upon the premise that accepting all types is good API design. Which it isn't, at all.
- zahlman 1y ago
  > But the entire post is built upon the premise that accepting all types is good API design. Which it isn't, at all. Was Tim Peters also wrong way back in the day when he counseled Guido van Rossum to allow floats to be added to integers without a cast, like other popular languages?
  - mjr00 1y ago
    How is `float | int` anywhere close to equivalent to `Any`?
    - MrJohz 1y ago
      How is "responds to the `__add__` method" anywhere close to equivalent to `Any`?
      - mjr00 1y ago
        If your implication is that "implementing __add__ means you can use the + operator", you are incorrect. This is a common Python beginner mistake, but it isn't really a Python type checking issue, this is complexity with Python built-ins and how they interact with magic methods. My suggestion -- don't rely on magic methods.
        jampekka 1y ago
        > My suggestion -- don't rely on magic methods. So no e.g. numpy or torch then?
        MrJohz 1y ago
        I guess that's the difference between the Python and the TypeScript approach here. In general, if something is possible, valid, and idiomatic in JavaScript, then TypeScript attempts to model it in the type system. That's how you get things like conditional types and mapped types that allow the type system to validate quite complex patterns. That makes the type system more complex, but it means that it's possible to use existing JavaScript patterns and code. TypeScript is quite deliberately not a new language, but a way of describing the implicit types used in JavaScript. Tools like `any` are therefore an absolute last resort, and you want to avoid it wherever possible. When I've used Python's type checkers, I have more the feeling that the goal is to create a new, typed subset of the language, that is less capable but also easier to apply types to. Then anything that falls outside that subset gets `Any` applied to it and that's good enough. The problem I find with that is that `Any` is incredibly infective - as soon as it shows up somewhere in a program, it's very difficult to prevent it from leaking all over the place, meaning you're often back in the same place you were before you added types, but now with the added nuisance of a bunch of types as documentation that you can't trust.
        zahlman 1y ago
- pdonis 1y ago
  > The Reddit post falls under the case of "don't know" the type. No, it doesn't. The desired type is known; it's "Addable" (i.e., "doesn't throw an exception when the built-in add operator is used"). The problem is expressing that in Python's type notation in a way that catches all edge cases. > If you want to allow users to pass in any objects, try to add and fail at runtime Which is not what the post author wants to do. They want to find a way to use Python's type notation to catch those errors with the type checker, so they don't happen at runtime. > the entire post is built upon the premise that accepting all types is good API design It is based on no such thing. I don't know where you're getting that from.
  - mjr00 1y ago
    > The desired type is known; it's "Addable" (i.e., "doesn't throw an exception when the built-in add operator is used"). The mistake both you and the reddit posts' author make is treating the `+` operator the same as you would an interface method. Despite Python having __add__/__radd__ methods, this isn't true, nor is it true in many other programming languages. For example, Go doesn't have a way to express "can use the + operator" at all, and "can use comparison operators" is defined as an explicit union between built-in types.[0] In C# you could only do this as of .NET 7, which was released in Nov 2022[1] -- was the C# type system unusable for the 17 years prior, when it didn't support this scenario? If this were any operation on `a` and `b` other than a built-in operator, such as `a.foo(b)`, it would be trivial to define a Protocol (which the author does in Step 4) and have everything work as expected. It's only because of misunderstanding of basic Python that the author continues to struggle for another 1000 words before concluding that type checking is bad. It's an extremely cherry-picked and unrealistic scenario either from someone who is clueless, or knows what they're doing and is intentionally being malicious in order to engagement bait.[2] This isn't to say Python (or Go, or C#) has the best type system, and it certainly lacks compared to Rust which is a very valid complaint, but "I can't express 'type which supports the '+' operator'" is an insanely esoteric and unusual case, unsupported in many languages, that it's disingenuous to use it as an excuse for why people shouldn't bother with type hinting at all. [0] https://pkg.go.dev/cmp#Ordered https://pkg.go.dev/cmp#Ordered [1] https://learn.microsoft.com/en-us/dotnet/standard/generics/math https://learn.microsoft.com/en-us/dotnet/standard/generics/m... [2] actually reading through the reddit comments, the author specifically says they were engagement baiting so... I guess they had enough Python knowledge to trick people into thinking type hinting was bad, fair enough!