3 ms·

> I still can’t quite figure out why type hinting is such a sought after feature. Same here. The arguments for it seem to be: - It allows you to find bugs in

by pansa2 6y ago

> I still can’t quite figure out why type hinting is such a sought after feature. Same here. The arguments for it seem to be: - It allows you to find bugs in your code without running it. I’ve concluded that my workflow must be different from people who make this claim - I never write code without testing it. This is more comprehensive than relying on a type checker, because it finds all kinds of errors, not just type errors. - It’s a form of documentation of function parameter and return types. This is better served by comments, because type hints are usually inaccurate in a duck-typed language like Python. For example, I see hints like `def twice(x: int) -> int: return x+x`. The correct type for a function like that isn’t `int`, it’s something like `addable`.

duckerude 6y ago
`addable` might be too broad. It describes the implementation, but not the intent. If you know that x is only ever an int then you can safely change the implementation to `return 2 * x`. Sometimes constraints give you extra possibilities.
- pansa2 6y ago
  I think this represents a difference in philosophy. I want to write functions once and use them wherever suitable, not write separate functions like twice_int, twice_string etc.
  - duckerude 6y ago
    You can write it for ints, figure out it's also useful for strings, and change the signature to also accept str. And then if you do ever want to change the implementation you can reason about the callers more easily and you won't have to create a new variant function for fear of breaking them. But perhaps that only makes sense for some functions. Probably not twice().
BerislavLopac 6y ago
That's called "protocols" in Python.
dragonwriter 6y ago
> It allows you to find bugs in your code without running it. I’ve concluded that my workflow must be different from people who make this claim - I never write code without testing it. Neither do I. IDE integrated typecheckoing still finds the kinds of bugs typing can find faster than IDE integrated unittesting, and often as they are being typed. > This is more comprehensive than relying on a type checker, because it finds all kinds of errors, not just type errors. It's still slower for the very broad class of errors a typechecker can highlight than static analysis, and unless you are very good at writing tests, far less comprehensive in that subcategory. > It’s a form of documentation of function parameter and return types. This is better served by comments, because type hints are usually inaccurate in a duck-typed language like Python. Conversely, it's better served by analytically confirmed annotations, because comments are usually inaccurate in most languages. > For example, I see hints like `def twice(x: int) -> int: return x+x`. The correct type for a function like that isn’t `int`, it’s something like `addable`. It's `int` if that's the promise I want to make to users that they can rely on and that I will fix bugs against and that I will adhere to in future changes that aren't SemVer major. That the implementation can supporting something broader is a private detail, not part of the API presented. It might use an optimized routine that relies on implementation details of Python ints tomorrow and just be using + today because correctness and delivery schedule beats optimization in this case. In fact, that possibility would be the only reason to a abstract something a simple as application of a simple binary operator OTOH, I frequently see argument or return value specs in comments that include types that are plain wrong, not subsets of what the underlying code supports.

by pansa2 6y ago

duckerude 6y ago

`addable` might be too broad. It describes the implementation, but not the intent. If you know that x is only ever an int then you can safely change the implementation to `return 2 * x`. Sometimes constraints give you extra possibilities.

pansa2 6y ago
I think this represents a difference in philosophy. I want to write functions once and use them wherever suitable, not write separate functions like twice_int, twice_string etc.
- duckerude 6y ago
  You can write it for ints, figure out it's also useful for strings, and change the signature to also accept str. And then if you do ever want to change the implementation you can reason about the callers more easily and you won't have to create a new variant function for fear of breaking them. But perhaps that only makes sense for some functions. Probably not twice().

BerislavLopac 6y ago

That's called "protocols" in Python.

dragonwriter 6y ago

> It allows you to find bugs in your code without running it. I’ve concluded that my workflow must be different from people who make this claim - I never write code without testing it. Neither do I. IDE integrated typecheckoing still finds the kinds of bugs typing can find faster than IDE integrated unittesting, and often as they are being typed. > This is more comprehensive than relying on a type checker, because it finds all kinds of errors, not just type errors. It's still slower for the very broad class of errors a typechecker can highlight than static analysis, and unless you are very good at writing tests, far less comprehensive in that subcategory. > It’s a form of documentation of function parameter and return types. This is better served by comments, because type hints are usually inaccurate in a duck-typed language like Python. Conversely, it's better served by analytically confirmed annotations, because comments are usually inaccurate in most languages. > For example, I see hints like `def twice(x: int) -> int: return x+x`. The correct type for a function like that isn’t `int`, it’s something like `addable`. It's `int` if that's the promise I want to make to users that they can rely on and that I will fix bugs against and that I will adhere to in future changes that aren't SemVer major. That the implementation can supporting something broader is a private detail, not part of the API presented. It might use an optimized routine that relies on implementation details of Python ints tomorrow and just be using + today because correctness and delivery schedule beats optimization in this case. In fact, that possibility would be the only reason to a abstract something a simple as application of a simple binary operator OTOH, I frequently see argument or return value specs in comments that include types that are plain wrong, not subsets of what the underlying code supports.