4 ms·

That's a lot of extra character overhead for not very much gain.

talideon 10y ago
It means that static analysis tools can do a much better job of finding issues in code, and will make code completion much better. I've worked on some pretty big Python codebases in my years, and both of those would be big wins. Currently people do the same thing in a much more janky and inconsistent way in docstrings.
- crdoconnor 10y ago
  Of the the large python code bases I've worked on (4 at current count), type errors have tended to account for a small proportion (around 4-8%) of production issues. If this feature came at relatively little cost this would be great - 5% of bugs squashed just like that. It doesn't. It contributes significantly to the verbosity of the code - chipping away at one of python's main strengths - concision and clarity.
  - geezerjay 10y ago
    > Of the the large python code bases I've worked on (4 at current count), type errors have tended to account for a small proportion (around 4-8%) of production issues. Some projects are more than eager to cut up to 8% of potential bugs with such a trivial change. >If this feature came at relatively little cost this would be great - 5% of bugs squashed just like that. It doesn't. It contributes significantly to the verbosity of the code - chipping away at one of python's main strengths - concision and clarity. I'm not sure you're being serious. Stating a type in a variable declaration doesn't harm concision, and obviously it does exactly the opposite of what you claim regarding clarity.
    - crdoconnor 10y ago
      >Some projects are more than eager to cut up to 8% of potential bugs with such a trivial change. Except it's not trivial, it's not 'free' - it adds noise to the code base and the idea it will eliminate all typing bugs is ludicrous. >Stating a type in a variable declaration doesn't harm concision Java is a good example of language that has explicit type declarations for every variable. That's one of the reasons why the average Java program is 2x as long as an equivalent python program. > obviously it does exactly the opposite of what you claim regarding clarity. No, not obviously. Are Java programs easier to read than python thanks to their explicit variable declarations and tendency towards verbosity?
      - geezerjay 10y ago
        > Except it's not trivial, it's not 'free' - it adds noise to the code base and the idea it will eliminate all typing bugs is ludicrous. Except it is trivial. Just add the type declaration like it says in the PEP. There. Problem solved. Who in their right mind makes a fuss for such a trivial thing? > That's one of the reasons why the average Java program is 2x as long as an equivalent python program. That's a ridiculous thing to say, and is entirely oblivious to the issue of boilerplate code that is mandatory in Java. > No, not obviously. Are Java programs easier to read than python thanks to their explicit variable declarations and tendency towards verbosity? You're trying to misrepresent a personal (and miss-guided) opinion that you formed on a particular programming language as being representative of a single issue. If your argument was sound and remotely rational, you would've pointed something in the PEP to discuss the merits of the PEP. Instead, you invent problems where there are none by making up stuff regarding an entirely different programming language. It sounds like you're very opinionated about something you clearly have no ground to criticize or comment on. Therefore it's pointless to continue with this discussion.
        crdoconnor 10y ago
        >Except it is trivial. Just add the type declaration like it says in the PEP. For every single variable declaration. This will increase the length of your program. >That's a ridiculous thing to say, Are you asserting that program length will not go up when adding explicit types? That seems a peculiarly indefensible position. >You're trying to misrepresent a personal (and miss-guided) opinion that you formed on a particular programming language as being representative of a single issue. Lack of verbosity is one of python's main strengths. >If your argument was sound and remotely rational, you would've pointed something in the PEP to discuss the merits of the PEP. Which I did which you would have picked up on if you were remotely reading what I was actually saying: it picks up type errors that would otherwise not be caught. It does that at a cost: longer code that does the same thing. You seem to fail to understand that this is a trade off. > Therefore it's pointless to continue with this discussion. Agree about that.
  - talideon 10y ago
    It's not just about that, but also about catching when people are doing type fuckery (that's really the best term I can come up with), i.e., doing silly things with the type system. I have one particular co-worker who's particularly bad when it comes to this. Also, while it works almost miraculously well as-is, type annotations would make the likes of Jedi much better. It might not seem like a big thing, but autocompletion is really useful with larger codebases and libraries you don't necessarily use every day. There's very little extra cost with this over and above what's currently there. All it's doing is formalising something people have been doing in docstrings for decades already.
  - talideon 10y ago
    > It contributes significantly to the verbosity of the code. No, it doesn't. The only places this is meant to be used is at interface points, i.e., declaring object member attributes and method/function signatures. We're not talking Java or C++ levels of type annotation here: we're talking Go, Haskell, and O'Caml levels of type annotation at most. And this is the core of the FUD around type annotations: people act like it's introducing Java and C++ levels of needless crud into the language, when the actual number of places where it's meant to be used is much smaller.
runeks 10y ago
Not very much gain? Maybe you are able to write Python without introducing type errors, but I know that I can't keep track of it, and it's my impression that the rest of the world's Pythonists can't either. At least when the project reaches a certain size. Scripting is another matter.
- crdoconnor 10y ago
  I've worked on multiple large projects, and while type errors are a problem, they aren't in the top 5 classes of 'most commonly reported bugs in production' - not if you have tests and a sprinkling of sanity checks, anyhow. Furthermore, the most common type errors I do see would be solved more effectively by stricter runtime error checking than they would be by slathering the language in static typing. For example: if not x: do_something() This example of perly weak runtime type checking is probably responsible for a larger proportion of bugs I see in production than most issues that static typing would solve. Ironically just a month ago a junior changed some of my code from : if x is not None: do_something() To: if not x: do_something() Because it was "more pythonic". Not long after he did that he hit a bug because it wasn't supposed to do_something() if x was a blank string. Whoops.
  - runeks 10y ago
    > I've worked on multiple large projects, and while type > errors are a problem, they aren't in the top 5 classes > of 'most commonly reported bugs in production' - not > if you have tests and a sprinkling of sanity checks, anyhow. My claim is that Pythonists are completely unaware that almost all of the errors they experience could have been avoided by just informing the compiler about what type a value is. I find it peculiar that people prefer writing tests to verify type correctness (a lot of work), rather than just having the compiler check it through simple type annotations. I say this coming from Python, having moved to to Haskell. Two diametrically opposite worlds in terms of type strictness. I think sprinkling type annotations all over the code is much preferable to writing test code. We have a type system such that the compiler can produce the code needed to check types, rather than us having to write this code in a test. In my humble opinion, humans shouldn't have to write test code. If you can't get the compiler to generate the test code you want - by constructing the types carefully - you're wasting a lot of time, because you have to write both the implementation, and a second implementation which tests the first one. So every time you do a rewrite, you also have to rewrite your tests, so that the two match. Double work.

It means that static analysis tools can do a much better job of finding issues in code, and will make code completion much better. I've worked on some pretty big Python codebases in my years, and both of those would be big wins. Currently people do the same thing in a much more janky and inconsistent way in docstrings.

crdoconnor 10y ago
Of the the large python code bases I've worked on (4 at current count), type errors have tended to account for a small proportion (around 4-8%) of production issues. If this feature came at relatively little cost this would be great - 5% of bugs squashed just like that. It doesn't. It contributes significantly to the verbosity of the code - chipping away at one of python's main strengths - concision and clarity.
- geezerjay 10y ago
  > Of the the large python code bases I've worked on (4 at current count), type errors have tended to account for a small proportion (around 4-8%) of production issues. Some projects are more than eager to cut up to 8% of potential bugs with such a trivial change. >If this feature came at relatively little cost this would be great - 5% of bugs squashed just like that. It doesn't. It contributes significantly to the verbosity of the code - chipping away at one of python's main strengths - concision and clarity. I'm not sure you're being serious. Stating a type in a variable declaration doesn't harm concision, and obviously it does exactly the opposite of what you claim regarding clarity.
  - crdoconnor 10y ago
    >Some projects are more than eager to cut up to 8% of potential bugs with such a trivial change. Except it's not trivial, it's not 'free' - it adds noise to the code base and the idea it will eliminate all typing bugs is ludicrous. >Stating a type in a variable declaration doesn't harm concision Java is a good example of language that has explicit type declarations for every variable. That's one of the reasons why the average Java program is 2x as long as an equivalent python program. > obviously it does exactly the opposite of what you claim regarding clarity. No, not obviously. Are Java programs easier to read than python thanks to their explicit variable declarations and tendency towards verbosity?
    - geezerjay 10y ago
      > Except it's not trivial, it's not 'free' - it adds noise to the code base and the idea it will eliminate all typing bugs is ludicrous. Except it is trivial. Just add the type declaration like it says in the PEP. There. Problem solved. Who in their right mind makes a fuss for such a trivial thing? > That's one of the reasons why the average Java program is 2x as long as an equivalent python program. That's a ridiculous thing to say, and is entirely oblivious to the issue of boilerplate code that is mandatory in Java. > No, not obviously. Are Java programs easier to read than python thanks to their explicit variable declarations and tendency towards verbosity? You're trying to misrepresent a personal (and miss-guided) opinion that you formed on a particular programming language as being representative of a single issue. If your argument was sound and remotely rational, you would've pointed something in the PEP to discuss the merits of the PEP. Instead, you invent problems where there are none by making up stuff regarding an entirely different programming language. It sounds like you're very opinionated about something you clearly have no ground to criticize or comment on. Therefore it's pointless to continue with this discussion.
      - crdoconnor 10y ago
        >Except it is trivial. Just add the type declaration like it says in the PEP. For every single variable declaration. This will increase the length of your program. >That's a ridiculous thing to say, Are you asserting that program length will not go up when adding explicit types? That seems a peculiarly indefensible position. >You're trying to misrepresent a personal (and miss-guided) opinion that you formed on a particular programming language as being representative of a single issue. Lack of verbosity is one of python's main strengths. >If your argument was sound and remotely rational, you would've pointed something in the PEP to discuss the merits of the PEP. Which I did which you would have picked up on if you were remotely reading what I was actually saying: it picks up type errors that would otherwise not be caught. It does that at a cost: longer code that does the same thing. You seem to fail to understand that this is a trade off. > Therefore it's pointless to continue with this discussion. Agree about that.
- talideon 10y ago
  It's not just about that, but also about catching when people are doing type fuckery (that's really the best term I can come up with), i.e., doing silly things with the type system. I have one particular co-worker who's particularly bad when it comes to this. Also, while it works almost miraculously well as-is, type annotations would make the likes of Jedi much better. It might not seem like a big thing, but autocompletion is really useful with larger codebases and libraries you don't necessarily use every day. There's very little extra cost with this over and above what's currently there. All it's doing is formalising something people have been doing in docstrings for decades already.
- talideon 10y ago
  > It contributes significantly to the verbosity of the code. No, it doesn't. The only places this is meant to be used is at interface points, i.e., declaring object member attributes and method/function signatures. We're not talking Java or C++ levels of type annotation here: we're talking Go, Haskell, and O'Caml levels of type annotation at most. And this is the core of the FUD around type annotations: people act like it's introducing Java and C++ levels of needless crud into the language, when the actual number of places where it's meant to be used is much smaller.

runeks 10y ago

Not very much gain? Maybe you are able to write Python without introducing type errors, but I know that I can't keep track of it, and it's my impression that the rest of the world's Pythonists can't either. At least when the project reaches a certain size. Scripting is another matter.

crdoconnor 10y ago
I've worked on multiple large projects, and while type errors are a problem, they aren't in the top 5 classes of 'most commonly reported bugs in production' - not if you have tests and a sprinkling of sanity checks, anyhow. Furthermore, the most common type errors I do see would be solved more effectively by stricter runtime error checking than they would be by slathering the language in static typing. For example: if not x: do_something() This example of perly weak runtime type checking is probably responsible for a larger proportion of bugs I see in production than most issues that static typing would solve. Ironically just a month ago a junior changed some of my code from : if x is not None: do_something() To: if not x: do_something() Because it was "more pythonic". Not long after he did that he hit a bug because it wasn't supposed to do_something() if x was a blank string. Whoops.
- runeks 10y ago
  > I've worked on multiple large projects, and while type > errors are a problem, they aren't in the top 5 classes > of 'most commonly reported bugs in production' - not > if you have tests and a sprinkling of sanity checks, anyhow. My claim is that Pythonists are completely unaware that almost all of the errors they experience could have been avoided by just informing the compiler about what type a value is. I find it peculiar that people prefer writing tests to verify type correctness (a lot of work), rather than just having the compiler check it through simple type annotations. I say this coming from Python, having moved to to Haskell. Two diametrically opposite worlds in terms of type strictness. I think sprinkling type annotations all over the code is much preferable to writing test code. We have a type system such that the compiler can produce the code needed to check types, rather than us having to write this code in a test. In my humble opinion, humans shouldn't have to write test code. If you can't get the compiler to generate the test code you want - by constructing the types carefully - you're wasting a lot of time, because you have to write both the implementation, and a second implementation which tests the first one. So every time you do a rewrite, you also have to rewrite your tests, so that the two match. Double work.