4 ms·

I don’t think that’s strictly true. Python developers are finding there are advantages to having a type system in larger programs such as readability and a redu

I don’t think that’s strictly true. Python developers are finding there are advantages to having a type system in larger programs such as readability and a reduction in certain classes of bugs. That said, I’ve found Python’s approach lets me still build things through experimentation then fixing the types when I’m a bit more confident that I’ve built the right thing. As a comparison, I found Go really clunky when I tried to learn it because it wouldn’t compile if the code wasn’t totally correct. It makes it hard to find the right solution through experimentation.

sinfulprogeny 2y ago
> then fixing the types man I wish my coworkers did this step
- scott_w 2y ago
  Having CI hard fail definitely helps. I won’t pretend I’d be so judicious without it.
  - camjw 2y ago
    Sorry this is probably a stupid question - how do you make your CI hard fail if you don't have types? This sounds like the missing piece for me, someone who also prefers just to crack on without types and then add them later.
    - spacemanspiffii 2y ago
      You can add `mypy` to your CI pipeline https://mypy.readthedocs.io/en/stable/running_mypy.html https://mypy.readthedocs.io/en/stable/running_mypy.html. Pyright is an alternative, and there are more.
    - scott_w 2y ago
      I was referring more specifically to fixing the types. It looks like it's possible to enforce type-hinting with config files to mypy (but I've not tried it): https://stackoverflow.com/questions/55944201/python-type-hinting-how-do-i-enforce-that-project-wide https://stackoverflow.com/questions/55944201/python-type-hin...
    - jascha_eng 2y ago
      Run mypy in strict mode and make that check required.
    - EasyMark 2y ago
      CI generally has a pipeline, no? Or even at worse a shell script that you built? Just add the equivalent of “exit()” when mypy (or whatever typing linter you’re using fails), and then the dev gets notified he broke the build for everyone. That’ll get them to fixing and checking their code before it goes in to the main branch. Peer pressure is underestimated these days I think.
josephg 2y ago
Python’s problem is that there’s multiple 3rd party type checkers and they all disagree in subtle ways about what the spec says. It’s a mess. Python is probably an all-round better language than JavaScript. But typescript absolutely embarrasses Python’s “gradual” type system with just how good it is in comparison.
- scott_w 2y ago
  I don’t see that as a problem since you’re not going to run multiple type checkers over your code, much like most C++ codebases pick a compiler and stick to it.
  - josephg 2y ago
    Nobody wants to recreate the mess of mutually incompatible c++ compilers. And it does matter when 3rd party libraries are involved. Types are a wonderful gift to anyone who imports & needs to figure out your library.
    - scott_w 2y ago
      > And it does matter when 3rd party libraries are involved. That's a fair point.
- setopt 2y ago
  I would love to instead have one official upstream runtime type checker which can be enabled per function, class, or module via decorators. Basically, providing opt-in strong typing as a language feature. Currently, I’m using the third-party Beartype decorators to provide this feature, but I would prefer something built-in and ideally something with more readable error messages for users when type errors occur, which might be easier to provide if it was built into Python. (I use Pyright too, but I find the runtime type checking to be more robust since it understands also the types returned by highly dynamic untyped code.)
noelwelsh 2y ago
Two things here: 1. You need to understand how to express concepts in a form the type system can understand. Each type system will have patterns it understands, and patterns it does not. 2. Go isn't a great example. It has a Java-circa-2000 type system. Modern type systems are much more expressive.
- scott_w 2y ago
  > Go isn't a great example. I picked Go as an example of a language that gets a lot of praise specifically for having strict compiler rules. I've also tried Scala and found it clunky but I do suspect most of its problems came from the insane operator overloading and opaque build system rather than the type system. I understand it's gotten better since I looked 8 years ago but I've not had a reason to check it out again.
  - noelwelsh 2y ago
    Yeah, the early days of Scala were a bad time for people going crazy with symbolic method names. Thankfully, most of that is in the past. (And Scala 3 is a much cleaner language in every way.)
  - never_inline 2y ago
    Those people haven't used Java 11+ or Python with types. Python with types is a double edged sword. If you can enforce other collaborators and SDKs use strict typing, it's a very pleasant experience to write, coupled with Pydantic for defining POJO-like structs. For CLI tools Click + Poetry build system. Java17+ type system is pretty good. Way better than Go in terms of dev experience. you may need a POJO generation tool (Lombok, Autovalue) and preferably validation libraries. I'd still write java over Go if efficiency and single binary is not a concern.
    - js2 2y ago
      > For CLI tools Click Once you're using types, I would recommend Typer instead. Built on-top of Click but configured via type hints: https://typer.tiangolo.com/ https://typer.tiangolo.com/
pif 2y ago
[flagged]
- noelwelsh 2y ago
  This is both rude and ignorant. There is great value to exploration and experimentation, particularly for beginner programmers. Type systems do get in the way, and I say this as someone with 20+ years experience of modern (Scala, Haskell) type systems.
  - pif 2y ago
    > There is great value to exploration and experimentation I agree. Typing in some code and trying to compile it is experimentation. Trying to fix the error in your code is exploration. Discarding the compiler's output as getting in the way means ignoring very, very precious advice.
    - ebalit 2y ago
      When you already know what you building, but not when you're doing exploratory data analysis for example. There is a good reason why the ML community took Python as the favorite language overall.
    - HelloNurse 2y ago
      Expecting an incorrect program to compile and run is a reckless spoiled brat attitude, not "exploration and experimentation". On the other hand heavyweight type systems that demand preemptively writing code to cover cases that won't happen and/or aren't important, including cases that make sense but aren't needed yet, can waste time actual exploration and experimentation, compared to writing only useful code and being sometimes surprised by runtime errors when the program accidentally attempts something not implemented yet. On the third hand "exploration and experimentation" can suffice for a proof of concept, not for production code: tests and automated checks are necessary to be confident about your program, and even rudimentary tools like Python type annotations and type checkers can be useful.
- scott_w 2y ago
maxbond 2y ago
> It makes it hard to find the right solution through experimentation. To me this suggests the tooling was insufficient. One of the things I value about type systems is being in a tight feedback loop with the compiler. Strong typing helps me run more experiments and to run them from within my editor. But without a good LSP and such, it would be miserable.
- scott_w 2y ago
  > To me this suggests the tooling was insufficient. Perhaps but I find that type systems usually introduce friction to getting things working that, for some types of projects, can be worthwhile and, for others, not worth the overhead.
  - maxbond 2y ago
    I think what you perceive as "friction" I perceive as "feedback," and it helps me work faster while writing code that's as good or better. When I interact with unfamiliar untyped code, it takes me longer to find my footing. So I don't find that there's overhead. I'm not dogmatic, type systems aren't the end all. But I think a lot of the trouble people have with them comes from using the approaches they've developed in untyped systems and saying, "this is the same, I just get more warnings and errors." But the opportunity is in developing new approaches and habits that leverage the type system. For me the "aha" moment was watching Jon Gjenset's YouTube videos, and seeing him intentionally write code with type errors in order to figure out what the type of something was. This helped me make the switch from thinking of errors as drudgery to be avoided to errors as feedback I may want to elicit. Now I'm able to answer lots of questions within my editor that I'd previously need to use a REPL or consult the docs to answer. It's like I'm able to query my codebase, but the query language is just the language I'm already working in. The magic of strong typing is good tooling.
    - scott_w 2y ago
      If it’s not clear: I like working with typed Python code. It absolutely solves a lot of issues that would require a stupid amount of testing and manual checking otherwise (dict-passing is a personal “favourite” I’ve seen). We shouldn’t pretend that it’s free. The fact is, sometimes running some code that I know works despite what the type system is telling me is very useful. Comparing to, say, Go, where I need to deal with everything (even if it’s incidental to the actual problem) adds friction. Sometimes I don’t want to deal with edge cases because this code will never leave my machine!
st3fan 2y ago
You can remove "larger programs". Personally I also find python typing useful in "smaller" programs and I use them pretty much everywhere. For example I use it in all my automation scripts which are usually not much longer than a few pages or a few modules. Adding type hints is a very minor task, really comes straight out of brain just like the code i type. Type hints have given me wonderful completion and documentation which has helped me to write more correct and bug free code. Often little things pop up that would only have been caught at runtime. Now I see those things as soon as I type them. Python + Type Hints == Awesome
- scott_w 2y ago
  If it works for you, great. I’ll also do that for the same reasons. What I really love, though, is I don’t need to be totally correct in my types all the time. If the code will run, it’ll run and, in plenty of simple cases, that’s good enough (even if mypy tells me I passed the wrong type).
paulddraper 2y ago
> because it wouldn’t compile if the code wasn’t totally correct Go won't even compile if a variable is unused. Makes it really hard to comment-out lines when debugging.

sinfulprogeny 2y ago

> then fixing the types man I wish my coworkers did this step

scott_w 2y ago
Having CI hard fail definitely helps. I won’t pretend I’d be so judicious without it.
- camjw 2y ago
  Sorry this is probably a stupid question - how do you make your CI hard fail if you don't have types? This sounds like the missing piece for me, someone who also prefers just to crack on without types and then add them later.
  - spacemanspiffii 2y ago
    You can add `mypy` to your CI pipeline https://mypy.readthedocs.io/en/stable/running_mypy.html https://mypy.readthedocs.io/en/stable/running_mypy.html. Pyright is an alternative, and there are more.
  - scott_w 2y ago
    I was referring more specifically to fixing the types. It looks like it's possible to enforce type-hinting with config files to mypy (but I've not tried it): https://stackoverflow.com/questions/55944201/python-type-hinting-how-do-i-enforce-that-project-wide https://stackoverflow.com/questions/55944201/python-type-hin...
  - jascha_eng 2y ago
    Run mypy in strict mode and make that check required.
  - EasyMark 2y ago
    CI generally has a pipeline, no? Or even at worse a shell script that you built? Just add the equivalent of “exit()” when mypy (or whatever typing linter you’re using fails), and then the dev gets notified he broke the build for everyone. That’ll get them to fixing and checking their code before it goes in to the main branch. Peer pressure is underestimated these days I think.

josephg 2y ago

Python’s problem is that there’s multiple 3rd party type checkers and they all disagree in subtle ways about what the spec says. It’s a mess. Python is probably an all-round better language than JavaScript. But typescript absolutely embarrasses Python’s “gradual” type system with just how good it is in comparison.

scott_w 2y ago
I don’t see that as a problem since you’re not going to run multiple type checkers over your code, much like most C++ codebases pick a compiler and stick to it.
- josephg 2y ago
  Nobody wants to recreate the mess of mutually incompatible c++ compilers. And it does matter when 3rd party libraries are involved. Types are a wonderful gift to anyone who imports & needs to figure out your library.
  - scott_w 2y ago
    > And it does matter when 3rd party libraries are involved. That's a fair point.
setopt 2y ago
I would love to instead have one official upstream runtime type checker which can be enabled per function, class, or module via decorators. Basically, providing opt-in strong typing as a language feature. Currently, I’m using the third-party Beartype decorators to provide this feature, but I would prefer something built-in and ideally something with more readable error messages for users when type errors occur, which might be easier to provide if it was built into Python. (I use Pyright too, but I find the runtime type checking to be more robust since it understands also the types returned by highly dynamic untyped code.)

noelwelsh 2y ago

Two things here: 1. You need to understand how to express concepts in a form the type system can understand. Each type system will have patterns it understands, and patterns it does not. 2. Go isn't a great example. It has a Java-circa-2000 type system. Modern type systems are much more expressive.

scott_w 2y ago
> Go isn't a great example. I picked Go as an example of a language that gets a lot of praise specifically for having strict compiler rules. I've also tried Scala and found it clunky but I do suspect most of its problems came from the insane operator overloading and opaque build system rather than the type system. I understand it's gotten better since I looked 8 years ago but I've not had a reason to check it out again.
- noelwelsh 2y ago
  Yeah, the early days of Scala were a bad time for people going crazy with symbolic method names. Thankfully, most of that is in the past. (And Scala 3 is a much cleaner language in every way.)
- never_inline 2y ago
  Those people haven't used Java 11+ or Python with types. Python with types is a double edged sword. If you can enforce other collaborators and SDKs use strict typing, it's a very pleasant experience to write, coupled with Pydantic for defining POJO-like structs. For CLI tools Click + Poetry build system. Java17+ type system is pretty good. Way better than Go in terms of dev experience. you may need a POJO generation tool (Lombok, Autovalue) and preferably validation libraries. I'd still write java over Go if efficiency and single binary is not a concern.
  - js2 2y ago
    > For CLI tools Click Once you're using types, I would recommend Typer instead. Built on-top of Click but configured via type hints: https://typer.tiangolo.com/ https://typer.tiangolo.com/

pif 2y ago

[flagged]

noelwelsh 2y ago
This is both rude and ignorant. There is great value to exploration and experimentation, particularly for beginner programmers. Type systems do get in the way, and I say this as someone with 20+ years experience of modern (Scala, Haskell) type systems.
- pif 2y ago
  > There is great value to exploration and experimentation I agree. Typing in some code and trying to compile it is experimentation. Trying to fix the error in your code is exploration. Discarding the compiler's output as getting in the way means ignoring very, very precious advice.
  - ebalit 2y ago
    When you already know what you building, but not when you're doing exploratory data analysis for example. There is a good reason why the ML community took Python as the favorite language overall.
  - HelloNurse 2y ago
    Expecting an incorrect program to compile and run is a reckless spoiled brat attitude, not "exploration and experimentation". On the other hand heavyweight type systems that demand preemptively writing code to cover cases that won't happen and/or aren't important, including cases that make sense but aren't needed yet, can waste time actual exploration and experimentation, compared to writing only useful code and being sometimes surprised by runtime errors when the program accidentally attempts something not implemented yet. On the third hand "exploration and experimentation" can suffice for a proof of concept, not for production code: tests and automated checks are necessary to be confident about your program, and even rudimentary tools like Python type annotations and type checkers can be useful.
scott_w 2y ago

maxbond 2y ago

> It makes it hard to find the right solution through experimentation. To me this suggests the tooling was insufficient. One of the things I value about type systems is being in a tight feedback loop with the compiler. Strong typing helps me run more experiments and to run them from within my editor. But without a good LSP and such, it would be miserable.

scott_w 2y ago
> To me this suggests the tooling was insufficient. Perhaps but I find that type systems usually introduce friction to getting things working that, for some types of projects, can be worthwhile and, for others, not worth the overhead.
- maxbond 2y ago
  I think what you perceive as "friction" I perceive as "feedback," and it helps me work faster while writing code that's as good or better. When I interact with unfamiliar untyped code, it takes me longer to find my footing. So I don't find that there's overhead. I'm not dogmatic, type systems aren't the end all. But I think a lot of the trouble people have with them comes from using the approaches they've developed in untyped systems and saying, "this is the same, I just get more warnings and errors." But the opportunity is in developing new approaches and habits that leverage the type system. For me the "aha" moment was watching Jon Gjenset's YouTube videos, and seeing him intentionally write code with type errors in order to figure out what the type of something was. This helped me make the switch from thinking of errors as drudgery to be avoided to errors as feedback I may want to elicit. Now I'm able to answer lots of questions within my editor that I'd previously need to use a REPL or consult the docs to answer. It's like I'm able to query my codebase, but the query language is just the language I'm already working in. The magic of strong typing is good tooling.
  - scott_w 2y ago
    If it’s not clear: I like working with typed Python code. It absolutely solves a lot of issues that would require a stupid amount of testing and manual checking otherwise (dict-passing is a personal “favourite” I’ve seen). We shouldn’t pretend that it’s free. The fact is, sometimes running some code that I know works despite what the type system is telling me is very useful. Comparing to, say, Go, where I need to deal with everything (even if it’s incidental to the actual problem) adds friction. Sometimes I don’t want to deal with edge cases because this code will never leave my machine!

st3fan 2y ago

You can remove "larger programs". Personally I also find python typing useful in "smaller" programs and I use them pretty much everywhere. For example I use it in all my automation scripts which are usually not much longer than a few pages or a few modules. Adding type hints is a very minor task, really comes straight out of brain just like the code i type. Type hints have given me wonderful completion and documentation which has helped me to write more correct and bug free code. Often little things pop up that would only have been caught at runtime. Now I see those things as soon as I type them. Python + Type Hints == Awesome

scott_w 2y ago
If it works for you, great. I’ll also do that for the same reasons. What I really love, though, is I don’t need to be totally correct in my types all the time. If the code will run, it’ll run and, in plenty of simple cases, that’s good enough (even if mypy tells me I passed the wrong type).

paulddraper 2y ago

> because it wouldn’t compile if the code wasn’t totally correct Go won't even compile if a variable is unused. Makes it really hard to comment-out lines when debugging.