8 ms·

I would have to say that I agree. A friend of mine put it this way, "If you expect me to put specify a type and not enforce it, you're just trolling".

mixmastamyk 11y ago
It's an optional addition to a dynamic scripting language. Lightweight when you need it, more robust when you need it. Sounds like you are trolling.
- 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.

mixmastamyk 11y ago

It's an optional addition to a dynamic scripting language. Lightweight when you need it, more robust when you need it. Sounds like you are trolling.

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.