4 ms·

Honest question: what's the point of type hinting without type checking? I must be mistaken, but I always thought "type hinting" was a synonym of "optional typ

by the_af 5y ago

Honest question: what's the point of type hinting without type checking? I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point, what are they good for?

xarope 5y ago
as a reminder for yourself/others who need to read/maintain your code? (I am often reminded of my perl days, where something I thought idiomatic 3 days ago, is now completely incomprehensible when I just want to make a minor change)
- the_af 5y ago
  So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).
  - zokier 5y ago
    yes, and yes. and they are still useful.
  - rglullis 5y ago
    You can have mypy doing the type checking. Just put it on your CI pipeline alongside your tests.
    - the_af 5y ago
      I know because I tried setting it up. It's slow, requires too much babysitting, and fails to catch cases. In my experience, it just doesn't work cleanly out of the box like in true statically typed languages, and so I get pushback from my coworkers, who simply can't see the point. And I can't blame them.
      - rglullis 5y ago
        Do your co-workers also only see the point of automated testing if you have 100% coverage? If you/your team want to use a statically typed language, then use one. Python is not it.
        the_af 5y ago
        You get me wrong: my coworkers struggle to see the point of testing at all. Usually they can be sold on the path of maximum-reward-for-minimum-effort. Hard to enforce/check type hints are not it (they seem like busywork for no actual payoff). With statically typed languages, the ROI would be different: they would either get the thing to compile, or they wouldn't and leave the job. This sounds drastic but it's really not: outside the realm of purist conversations between fans of programming languages, people just want to do their job and get it over with. If the tooling is convoluted, has too many rules, or they aren't forced to use it ("...or else"), they just won't. This is a javascript/python shop, by the way. We cannot choose the languages. We can improve the tooling and train the team with better practices though. > If you/your team want to use a statically typed language, then use one. Python is not it. This is a bit of a cop out though, isn't it? A response to criticism of a (possibly) flawed language feature cannot really be "well, use another language". How else will the language improve then?
        TillE 5y ago
        Your criticism was: > it just doesn't work cleanly out of the box like in true statically typed languages So the response is entirely appropriate. Python is not a statically typed language, of course type hints don't make it behave exactly like a statically typed language.
        the_af 5y ago
        Fair enough. I can see how my statement was not very clear. I meant to say this: because Python's type hints don't work as well as true statically typed languages (based on my own experience), this makes them less useful and also makes them feel more like busywork. Because of this, my coworkers (who have no experience with statically typed languages either, and tend to dislike best practices and features unless they see a clear return of value from them) are hard to convince type hints are worth the time to learn and use them. Also, let me restate we cannot pick the language. We can just make better or worse use of it.
  - xarope 5y ago
    it's a comment which can trigger an action (if you run mypy). So, unlike a comment, which does nothing, if you run mypy and get some warnings, you can then do something about it (whether it's just # type: ignore or you realise you made a mistake with allocating to variable new_value versus newvalue/new_valu/etc) (btw, in case someone objects, some comments DO do something, e.g. golang's godoc examples)
    - the_af 5y ago
      Now I'm confused because the root comment I was replying to asserted that type hints are for documenting, not for checking. If they are for checking, then my other opinion stands: that they are not very good at it (compared to my experience with statically typed languages, even with Typescript!).
      - dragonwriter 5y ago
        They are for documenting and checking. Obviously, if static typing is your only concern, you wouldn't have picked Python to start with, but if you did have a reason to pick Python, you can get a large subset of the value of static typing for correctness and dev-tine information via Python’s support for type hints and the typecheckers (mypy keeps getting pointed to, but it's not the only one) that support it.
        the_af 5y ago
        Yes, obviously. There are outside factors why Python was chosen. I tend to work with whatever language is needed, and try to make the best of it. I've tried mypy and pytype, and found both to be unsatisfying and hard to sell to the team (which as I mentioned, don't even like writing tests). If you're thinking "well, that's a culture/professionalism rather than a technical problem", you are absolutely right! But I'm left wondering if a language that was better at static typing would be better because, a- the checking would be mandatory, and b- it would be demonstrably more effective than Python's "optional" checking/hinting. At least it'd remove one variable from the problem. Or maybe not, who knows.
  - dragonwriter 5y ago
    > So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. If your team doesn't understand the value of things that are essentially standardized comments exposed through the IDE (even if it wasn't for validation, which is also available with IDE integration), you have very bad teammates.
    - the_af 5y ago
      As I said in another reply to a comment of yours: maybe so. I cannot do anything about my team mates, but I can push for tools that make the upside of their usage more evident. "Standardized comments", when working with inexperienced/resistant team mates, is not such obviously good tool. In my opinion, of course.
gnulinux 5y ago
It is good for programmers. Programmers think in many different ways, but it seems to me that a sizable portion of programmers think of code in terms types. Type hinting makes it easy to convey type ideas. Where are we going from which type. I should say that anecdotally I find type hinting very useful when I'm reviewing a PR from a part of the code I'm not intensely familiar with.
- the_af 5y ago
  So a concise but not-legally-binding notation for types? Useful, but way less useful than if it was actually checked.
- nine_zeros 5y ago
  Just put types in docstrings? Why type hinting with imports and other dependencies, especially for complex objects?
- minusf 5y ago
  when types are not checked and enforced, they get out of date just like comments and docstrings. i agree with the author, if the hints can't be trusted, even just once, there's no point littering the code with them, and are actually harmful when trying to debug something using faulty hints. i am a big fan of static typing but not in python. pick a language that was designed around it. you can't make a duck bark.
  - icedchai 5y ago
    For libraries, with many consumers of the code, type hinting seems like a good thing. Many times I download a third-party library and waste tons of time looking at sample code. For application code (internal to the service or whatever), it feels less valuable.
deleted 5y ago
[deleted]
the__alchemist 5y ago
The IDE catches type errors, and it lets you do things like simulate structs using @dataclass.
- the_af 5y ago
  I wish the tooling outside IDEs worked better. There's obviously some magic going on with tools like PyCharm and VSCode + plugins. I wish this was the case with command line tools I can plug into the build/deploy pipeline. I know they exist, it's just they are unsatisfying and there are lots of cases where they miss stuff that is trivial to catch in statically typed languages.
  - nomel 5y ago
    As someone who lives in an IDE, I don't understand this. Trying to get all of the functionality of the default IDE, along with the trivially added plugins, to work in a visually digestible and sane way would be a curses nightmare of 30 command line tools. If you made it so they played well together, where a human could interpret what they were seeing, you would have something indistinguishable from an IDE.
    - the_af 5y ago
      I find your opinion baffling to be honest. It's simply not true. Every statically typed language works like I described. Even Typescript works like this. You can have your IDE plugins, but you definitely don't need them to perform type checks. It's not true this requires "a nightmare of 30 command line tools", you just need one: the type checker (built into the language in most statically typed languages, but sometimes split into a separate tool). Besides, your IDE doesn't live in the build pipeline (in your CI/CD tool). So you cannot rely on it.
      - nomel 5y ago
        Sorry, I misread your comment.
- 5y ago
hoosieree 5y ago
Just a couple hours ago, a student asked me what was the type of a parameter in a function I wrote. A type hint would have answered their question immediately (as they were reading the code).
- the_af 5y ago
  Yes, but checked type annotations will do the same, plus they are actually enforced. An unenforced type hint is just like any comment: likely to get out of sync with the code, and a human must do all the work of keeping it up to date.
fluster 5y ago
I view them as similar to python's "private" functions, which are really just functions starting with an underscore. The interpreter will let anyone call them like any other function, but the general rule is don't do it, unless you know what you're doing and are willing to deal with the internals changing. Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need. Do either of these things do anything comments couldn't? Not really. But they're ways of indicating intended semantics without formally documenting your stuff, and when most of what you use the language for is scripts, that's actually pretty helpful. People actually use type hints in a way they didn't with comments, and that's caused a major improvement in code readability. Or at least that's been my experience You can absolutely look at all this and say python's a crazy, terrible language you never want to touch, but if you've got no choice on language for whatever reason, or you're throwing something together and don't feel like writing `private static final synchronized` forty time, type hints are great.
- giyanani 5y ago
  The typing (>= python 3.6?) and collections (>= python 3.8?) packages have definitions for a bunch of protocols (basically interfaces for structural typing). So for that List[int] example, you probably want to take a(n) Iterable[int], Iterator[int], or Collection[int] instead, depending on exactly how you use it.
- the_af 5y ago
  Thanks for your reply. > I view them as similar to python's "private" functions, which are really just functions starting with an underscore Good analogy! I wish they were more like "private" class methods, which are prefixed by a double underscore and result in name-mangling: you can still access them from outside if you want, but the code will really look ugly. And you absolutely cannot access them accidentally. Which is what type checking should be all about, right? Preventing accidental misuse? > Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need. That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view. "These types are just something someone wrote, they may or may not accurately describe the code" seems so wasteful and unhelpful to me...
rurp 5y ago
They are useful for catching issue before code is committed or deployed. At my work we run mypy as part of our test suite, so failing type checks will block a merge or deploy.
- the_af 5y ago
  How will they catch issues if they are not checked? The comment I'm replying to insinuated type hinting is just for documentation, and not necessarily meant to be actually checked by the tooling. You seem to be describing actual type checking, which I understand (though in my opinion, mypy is not a satisfying tool for this).

by the_af 5y ago

xarope 5y ago

as a reminder for yourself/others who need to read/maintain your code? (I am often reminded of my perl days, where something I thought idiomatic 3 days ago, is now completely incomprehensible when I just want to make a minor change)

the_af 5y ago
So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).
- zokier 5y ago
  yes, and yes. and they are still useful.
- rglullis 5y ago
  You can have mypy doing the type checking. Just put it on your CI pipeline alongside your tests.
  - the_af 5y ago
    I know because I tried setting it up. It's slow, requires too much babysitting, and fails to catch cases. In my experience, it just doesn't work cleanly out of the box like in true statically typed languages, and so I get pushback from my coworkers, who simply can't see the point. And I can't blame them.
    - rglullis 5y ago
      Do your co-workers also only see the point of automated testing if you have 100% coverage? If you/your team want to use a statically typed language, then use one. Python is not it.
      - the_af 5y ago
        You get me wrong: my coworkers struggle to see the point of testing at all. Usually they can be sold on the path of maximum-reward-for-minimum-effort. Hard to enforce/check type hints are not it (they seem like busywork for no actual payoff). With statically typed languages, the ROI would be different: they would either get the thing to compile, or they wouldn't and leave the job. This sounds drastic but it's really not: outside the realm of purist conversations between fans of programming languages, people just want to do their job and get it over with. If the tooling is convoluted, has too many rules, or they aren't forced to use it ("...or else"), they just won't. This is a javascript/python shop, by the way. We cannot choose the languages. We can improve the tooling and train the team with better practices though. > If you/your team want to use a statically typed language, then use one. Python is not it. This is a bit of a cop out though, isn't it? A response to criticism of a (possibly) flawed language feature cannot really be "well, use another language". How else will the language improve then?
        TillE 5y ago
        Your criticism was: > it just doesn't work cleanly out of the box like in true statically typed languages So the response is entirely appropriate. Python is not a statically typed language, of course type hints don't make it behave exactly like a statically typed language.
        the_af 5y ago
        Fair enough. I can see how my statement was not very clear. I meant to say this: because Python's type hints don't work as well as true statically typed languages (based on my own experience), this makes them less useful and also makes them feel more like busywork. Because of this, my coworkers (who have no experience with statically typed languages either, and tend to dislike best practices and features unless they see a clear return of value from them) are hard to convince type hints are worth the time to learn and use them. Also, let me restate we cannot pick the language. We can just make better or worse use of it.
- xarope 5y ago
  it's a comment which can trigger an action (if you run mypy). So, unlike a comment, which does nothing, if you run mypy and get some warnings, you can then do something about it (whether it's just # type: ignore or you realise you made a mistake with allocating to variable new_value versus newvalue/new_valu/etc) (btw, in case someone objects, some comments DO do something, e.g. golang's godoc examples)
  - the_af 5y ago
    Now I'm confused because the root comment I was replying to asserted that type hints are for documenting, not for checking. If they are for checking, then my other opinion stands: that they are not very good at it (compared to my experience with statically typed languages, even with Typescript!).
    - dragonwriter 5y ago
      They are for documenting and checking. Obviously, if static typing is your only concern, you wouldn't have picked Python to start with, but if you did have a reason to pick Python, you can get a large subset of the value of static typing for correctness and dev-tine information via Python’s support for type hints and the typecheckers (mypy keeps getting pointed to, but it's not the only one) that support it.
      - the_af 5y ago
        Yes, obviously. There are outside factors why Python was chosen. I tend to work with whatever language is needed, and try to make the best of it. I've tried mypy and pytype, and found both to be unsatisfying and hard to sell to the team (which as I mentioned, don't even like writing tests). If you're thinking "well, that's a culture/professionalism rather than a technical problem", you are absolutely right! But I'm left wondering if a language that was better at static typing would be better because, a- the checking would be mandatory, and b- it would be demonstrably more effective than Python's "optional" checking/hinting. At least it'd remove one variable from the problem. Or maybe not, who knows.
- dragonwriter 5y ago
  > So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. If your team doesn't understand the value of things that are essentially standardized comments exposed through the IDE (even if it wasn't for validation, which is also available with IDE integration), you have very bad teammates.
  - the_af 5y ago
    As I said in another reply to a comment of yours: maybe so. I cannot do anything about my team mates, but I can push for tools that make the upside of their usage more evident. "Standardized comments", when working with inexperienced/resistant team mates, is not such obviously good tool. In my opinion, of course.

gnulinux 5y ago

It is good for programmers. Programmers think in many different ways, but it seems to me that a sizable portion of programmers think of code in terms types. Type hinting makes it easy to convey type ideas. Where are we going from which type. I should say that anecdotally I find type hinting very useful when I'm reviewing a PR from a part of the code I'm not intensely familiar with.

the_af 5y ago
So a concise but not-legally-binding notation for types? Useful, but way less useful than if it was actually checked.
nine_zeros 5y ago
Just put types in docstrings? Why type hinting with imports and other dependencies, especially for complex objects?
minusf 5y ago
when types are not checked and enforced, they get out of date just like comments and docstrings. i agree with the author, if the hints can't be trusted, even just once, there's no point littering the code with them, and are actually harmful when trying to debug something using faulty hints. i am a big fan of static typing but not in python. pick a language that was designed around it. you can't make a duck bark.
- icedchai 5y ago
  For libraries, with many consumers of the code, type hinting seems like a good thing. Many times I download a third-party library and waste tons of time looking at sample code. For application code (internal to the service or whatever), it feels less valuable.

deleted 5y ago

[deleted]

the__alchemist 5y ago

The IDE catches type errors, and it lets you do things like simulate structs using @dataclass.

the_af 5y ago
I wish the tooling outside IDEs worked better. There's obviously some magic going on with tools like PyCharm and VSCode + plugins. I wish this was the case with command line tools I can plug into the build/deploy pipeline. I know they exist, it's just they are unsatisfying and there are lots of cases where they miss stuff that is trivial to catch in statically typed languages.
- nomel 5y ago
  As someone who lives in an IDE, I don't understand this. Trying to get all of the functionality of the default IDE, along with the trivially added plugins, to work in a visually digestible and sane way would be a curses nightmare of 30 command line tools. If you made it so they played well together, where a human could interpret what they were seeing, you would have something indistinguishable from an IDE.
  - the_af 5y ago
    I find your opinion baffling to be honest. It's simply not true. Every statically typed language works like I described. Even Typescript works like this. You can have your IDE plugins, but you definitely don't need them to perform type checks. It's not true this requires "a nightmare of 30 command line tools", you just need one: the type checker (built into the language in most statically typed languages, but sometimes split into a separate tool). Besides, your IDE doesn't live in the build pipeline (in your CI/CD tool). So you cannot rely on it.
    - nomel 5y ago
      Sorry, I misread your comment.
5y ago

hoosieree 5y ago

Just a couple hours ago, a student asked me what was the type of a parameter in a function I wrote. A type hint would have answered their question immediately (as they were reading the code).

the_af 5y ago
Yes, but checked type annotations will do the same, plus they are actually enforced. An unenforced type hint is just like any comment: likely to get out of sync with the code, and a human must do all the work of keeping it up to date.

fluster 5y ago

I view them as similar to python's "private" functions, which are really just functions starting with an underscore. The interpreter will let anyone call them like any other function, but the general rule is don't do it, unless you know what you're doing and are willing to deal with the internals changing. Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need. Do either of these things do anything comments couldn't? Not really. But they're ways of indicating intended semantics without formally documenting your stuff, and when most of what you use the language for is scripts, that's actually pretty helpful. People actually use type hints in a way they didn't with comments, and that's caused a major improvement in code readability. Or at least that's been my experience You can absolutely look at all this and say python's a crazy, terrible language you never want to touch, but if you've got no choice on language for whatever reason, or you're throwing something together and don't feel like writing `private static final synchronized` forty time, type hints are great.

giyanani 5y ago
The typing (>= python 3.6?) and collections (>= python 3.8?) packages have definitions for a bunch of protocols (basically interfaces for structural typing). So for that List[int] example, you probably want to take a(n) Iterable[int], Iterator[int], or Collection[int] instead, depending on exactly how you use it.
the_af 5y ago
Thanks for your reply. > I view them as similar to python's "private" functions, which are really just functions starting with an underscore Good analogy! I wish they were more like "private" class methods, which are prefixed by a double underscore and result in name-mangling: you can still access them from outside if you want, but the code will really look ugly. And you absolutely cannot access them accidentally. Which is what type checking should be all about, right? Preventing accidental misuse? > Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need. That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view. "These types are just something someone wrote, they may or may not accurately describe the code" seems so wasteful and unhelpful to me...

rurp 5y ago

They are useful for catching issue before code is committed or deployed. At my work we run mypy as part of our test suite, so failing type checks will block a merge or deploy.

the_af 5y ago
How will they catch issues if they are not checked? The comment I'm replying to insinuated type hinting is just for documentation, and not necessarily meant to be actually checked by the tooling. You seem to be describing actual type checking, which I understand (though in my opinion, mypy is not a satisfying tool for this).