5 ms·

It's not more robust though. The type hints do absolutely nothing.

by DasIch 11y ago

mixmastamyk 11y ago
False, they provide information to analysis tools, which can prevent errors.
ubernostrum 11y ago
If there is a tool which statically analyzes your code and reports errors due to type mismatches, does it matter to you whether that tool has the exact literal name "ahead-of-time compiler"?
- lmm 11y ago
  What does matter to me is whether the standard build tool for the language will run that tool on a proposed library release before that library gets uploaded to PyPI (or equivalent). If there are type annotations in the standard package repository that are lies then that seriously limits the usefulness of the whole thing.
  - orf 11y ago
    > If there are type annotations in the standard package repository There aren't. > whether the standard build tool for the language will run that tool on a proposed library release before that library gets uploaded to PyPI It's optional. If the library maintainer wants to do that then he can.
    - lmm 11y ago
      > It's optional. If the library maintainer wants to do that then he can. A library with no annotations in PyPI is fine-ish. A library with correct annotations in PyPI is fine. A library with incorrect annotations in PyPI is extremely not-fine. I'm fine-ish with annotations being optional, but if they're there then their correctness needs to be enforced, otherwise they're worse than useless.
      - orf 11y ago
        > A library with incorrect annotations in PyPI is extremely not-fine. As is a library with broken logic or one that throws exceptions randomly. You want Guido and the developers to implement some kind of system that automatically scans all PyPi packages for any kind of errors? I'm sure them solving the halting problem won't take that long. Incorrect annotations are a bug. The onus is on the maintainers of packages to fix bugs in their packages, not PyPi which is a distribution channel.
        lmm 11y ago
        > As is a library with broken logic or one that throws exceptions randomly. You want Guido and the developers to implement some kind of system that automatically scans all PyPi packages for any kind of errors? Yes I do, but perfect is the enemy of good; it's ok to do something that makes things better without solving the whole problem. I want the build system to encourage people to do the right thing. E.g. any serious build system already ensures that you run the unit tests as part of the build or at least release process, because it would be just dumb to publish a library release on PyPI if it failed the unit tests. > I'm sure them solving the halting problem won't take that long. We already know how to avoid the halting problem, it's called types; see e.g. Idris. But you don't need to solve the halting problem to check annotations. It's not even hard. Why would you want to not check them? I mean if you're not even going to check them then why bother having annotations in the first place? Comments would provide the same functionality and have less danger of being misleading, because everyone already knows comments often end up being out of date.
        orf 11y ago
        I'm really confused here. Are you really advocating that PyPi performs some kind of magic on the thousands and thousands of packages that are uploaded to ensure that all their unit tests pass, including testing the type annotations? Can you please give me an example of another languages packaging site with a non-trivial amount of packages that does this, or at least explain why this isn't the developers responsibility? All you seem to be saying is that "Code should be tested before being uploaded to PyPi", and somehow that equates to type annotations being bad? Again, it's up to the developer to ensure his tests pass (by using a ci, or running tests locally, or even making a blood sacrifice to Cthulhu), and yes this should include a linter to ensure type annotations are correct if they are using them.

It's not more robust though. The type hints do absolutely nothing.

by DasIch 11y ago

It's not more robust though. The type hints do absolutely nothing.

mixmastamyk 11y ago

False, they provide information to analysis tools, which can prevent errors.

ubernostrum 11y ago

If there is a tool which statically analyzes your code and reports errors due to type mismatches, does it matter to you whether that tool has the exact literal name "ahead-of-time compiler"?

lmm 11y ago
What does matter to me is whether the standard build tool for the language will run that tool on a proposed library release before that library gets uploaded to PyPI (or equivalent). If there are type annotations in the standard package repository that are lies then that seriously limits the usefulness of the whole thing.
- orf 11y ago
  > If there are type annotations in the standard package repository There aren't. > whether the standard build tool for the language will run that tool on a proposed library release before that library gets uploaded to PyPI It's optional. If the library maintainer wants to do that then he can.
  - lmm 11y ago
    > It's optional. If the library maintainer wants to do that then he can. A library with no annotations in PyPI is fine-ish. A library with correct annotations in PyPI is fine. A library with incorrect annotations in PyPI is extremely not-fine. I'm fine-ish with annotations being optional, but if they're there then their correctness needs to be enforced, otherwise they're worse than useless.
    - orf 11y ago
      > A library with incorrect annotations in PyPI is extremely not-fine. As is a library with broken logic or one that throws exceptions randomly. You want Guido and the developers to implement some kind of system that automatically scans all PyPi packages for any kind of errors? I'm sure them solving the halting problem won't take that long. Incorrect annotations are a bug. The onus is on the maintainers of packages to fix bugs in their packages, not PyPi which is a distribution channel.
      - lmm 11y ago
        > As is a library with broken logic or one that throws exceptions randomly. You want Guido and the developers to implement some kind of system that automatically scans all PyPi packages for any kind of errors? Yes I do, but perfect is the enemy of good; it's ok to do something that makes things better without solving the whole problem. I want the build system to encourage people to do the right thing. E.g. any serious build system already ensures that you run the unit tests as part of the build or at least release process, because it would be just dumb to publish a library release on PyPI if it failed the unit tests. > I'm sure them solving the halting problem won't take that long. We already know how to avoid the halting problem, it's called types; see e.g. Idris. But you don't need to solve the halting problem to check annotations. It's not even hard. Why would you want to not check them? I mean if you're not even going to check them then why bother having annotations in the first place? Comments would provide the same functionality and have less danger of being misleading, because everyone already knows comments often end up being out of date.
        orf 11y ago
        I'm really confused here. Are you really advocating that PyPi performs some kind of magic on the thousands and thousands of packages that are uploaded to ensure that all their unit tests pass, including testing the type annotations? Can you please give me an example of another languages packaging site with a non-trivial amount of packages that does this, or at least explain why this isn't the developers responsibility? All you seem to be saying is that "Code should be tested before being uploaded to PyPi", and somehow that equates to type annotations being bad? Again, it's up to the developer to ensure his tests pass (by using a ci, or running tests locally, or even making a blood sacrifice to Cthulhu), and yes this should include a linter to ensure type annotations are correct if they are using them.