8 ms·

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 bi

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.

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.