4 ms·

I would not personally use any of them. Typed python in previous workplace was pretty much shitshow, and if starting from scratch instead of untyped codebase it

I would not personally use any of them. Typed python in previous workplace was pretty much shitshow, and if starting from scratch instead of untyped codebase it might be worth it, maybe, for some specific cases, but in general combination of bad library typing and bad type checking tools leads to horrible user experience. So going forward my personal projects continue to be ducktyped, and if I care about types, I use rust or go.

nickm12 3y ago
My experience couldn't be more different. I've had the experience of introducing type annotations into legacy Python 2 codebases and it's been a godsend and the only way to get them to Python 3. I've also had the experience of writing greenfield Python 3 code fully-typed from the start and its also been a useful tool there.
- mixmastamyk 3y ago
  What does this mean, Python 2? Are those the old type comments?
  - zo1 3y ago
    Eclipse with PyDev had awesome support for types in python 2.* before they were a python 3 thing. It actually worked really well for the 90% usecase and was my secret weapon about a decade ago.
  - nickm12 3y ago
    Yes. Mypy supports type annotations provided in comments in both Python 2 and Python 3. I have ported a codebase from Python 2 to 3 by annotating it with comment-syntax annotations and it helps a ton to keep your strings and bytes separate. Basically, you annotate with the binary_type, text_type types the six package and typecheck your code on both Python 2 and Python 3. Basically, the steps involved are: 1. set up static analysis (linting and typechecking) for python 2 and python 3 2. get code passing static analysis on Py2 and Py3 3. get code passing tests on Py2 and Py3 4. get code running in production on Py3 5. stop checking and testing on Py2 It's not trivial and it requires some strong Python experience to write code that correctly "straddles" Py2 and Py3. But the advantage of the static checkers is you can slowly dial up their strictness and once they are dialed in, you minimize new regressions (new untyped code, new code that fails typechecking).
winrid 3y ago
Even the Stripe API types are terrible. I'm moving away from Python for my large projects...
emblaegh 3y ago
Whatever bad experience you get from the (admittedly) immature tooling, pales in comparison to the intense discomfort or working with an untyped Python code base of even moderate size, specially ones written by many different contributors.
- mixmastamyk 3y ago
  I’ve worked for a while rewriting a large crappy old etl codebase and types were not the problem at all. Really it needed a huge amount of reorg and refactoring, which a test suite and pyflakes handled quite well. https://news.ycombinator.com/item?id=39161025 https://news.ycombinator.com/item?id=39161025
IshKebab 3y ago
I have had the misfortune of having to work with untyped Python code. It is completely awful and I cannot imagine anyone genuinely prefers it. Impossible to navigate. Full of trivial type bugs and typos. Static typing makes Python tolerable.
- mixmastamyk 3y ago
  Pyflakes will catch most of those kinds of bugs. Fast option if for some reason you can’t or don’t have time to type.
  - IshKebab 3y ago
    No it won't. It won't even catch trivial errors like `import os; os.sdfsdfsdf()`. Perhaps you haven't used static typing so aren't familiar with the kinds of bugs it can prevent?
    - mixmastamyk 3y ago
      Doctor, it hurts when I punch myself in the face. I need something to prevent that. I’m talking about realistic errors, not theoretical ones that would crash at first run. You have one test, right? Run the code once before deploying? I thought so. In which case, pyflakes and a few tests find a great majority (not all) of errors devs actually have.
      - IshKebab 3y ago
        > pyflakes and a few tests find a great majority (not all) of errors devs actually have. No they don't. First of all people are really bad at writing tests. Secondly, writing tests sucks; I would much rather write static type annotations than tedious type checking tests: you know when to stop and you get the other benefits of static types like making the code easier to read and navigate. Every piece of code I've added static typing to has revealed bugs. One we later hit in production (because the author was stupidly against static typing so I gave up trying to help him). That bug was simply calling a method that didn't even exist. It was in a code path that wasn't tested, despite having some tests. But I can see you're from the school of "I don't make mistakes" and convincing you otherwise is about as effective as trying to persuade Christians there isn't a god.
yen223 3y ago
I agree. Type-checking in general is good. However, Python's type-checking mechanisms are bad. The syntax for adding types is very obviously bolted on, they miss basic type errors all the time, and third-party libraries often miss type annotations anyway. Python is fundamentally a duck-typed language, and that's how you should use it. If type-checking is important to you, use a language that is designed for it.
- roland35 3y ago
  Eh it's either Python or C++ with ROS, and Python is much easier to work with. Adding type checks to method arguments isn't much different than doing it in Rust, and makes life much easier with anything larger a tiny program. If there is anything complicated, you can either make a quick generic type (TypeVar) or even just throw in an Any type! I had to do that recently with a function that handled different ROS services, which apparently do not share any base class.

nickm12 3y ago

My experience couldn't be more different. I've had the experience of introducing type annotations into legacy Python 2 codebases and it's been a godsend and the only way to get them to Python 3. I've also had the experience of writing greenfield Python 3 code fully-typed from the start and its also been a useful tool there.

mixmastamyk 3y ago
What does this mean, Python 2? Are those the old type comments?
- zo1 3y ago
  Eclipse with PyDev had awesome support for types in python 2.* before they were a python 3 thing. It actually worked really well for the 90% usecase and was my secret weapon about a decade ago.
- nickm12 3y ago
  Yes. Mypy supports type annotations provided in comments in both Python 2 and Python 3. I have ported a codebase from Python 2 to 3 by annotating it with comment-syntax annotations and it helps a ton to keep your strings and bytes separate. Basically, you annotate with the binary_type, text_type types the six package and typecheck your code on both Python 2 and Python 3. Basically, the steps involved are: 1. set up static analysis (linting and typechecking) for python 2 and python 3 2. get code passing static analysis on Py2 and Py3 3. get code passing tests on Py2 and Py3 4. get code running in production on Py3 5. stop checking and testing on Py2 It's not trivial and it requires some strong Python experience to write code that correctly "straddles" Py2 and Py3. But the advantage of the static checkers is you can slowly dial up their strictness and once they are dialed in, you minimize new regressions (new untyped code, new code that fails typechecking).

winrid 3y ago

Even the Stripe API types are terrible. I'm moving away from Python for my large projects...

emblaegh 3y ago

Whatever bad experience you get from the (admittedly) immature tooling, pales in comparison to the intense discomfort or working with an untyped Python code base of even moderate size, specially ones written by many different contributors.

mixmastamyk 3y ago
I’ve worked for a while rewriting a large crappy old etl codebase and types were not the problem at all. Really it needed a huge amount of reorg and refactoring, which a test suite and pyflakes handled quite well. https://news.ycombinator.com/item?id=39161025 https://news.ycombinator.com/item?id=39161025

IshKebab 3y ago

I have had the misfortune of having to work with untyped Python code. It is completely awful and I cannot imagine anyone genuinely prefers it. Impossible to navigate. Full of trivial type bugs and typos. Static typing makes Python tolerable.

mixmastamyk 3y ago
Pyflakes will catch most of those kinds of bugs. Fast option if for some reason you can’t or don’t have time to type.
- IshKebab 3y ago
  No it won't. It won't even catch trivial errors like `import os; os.sdfsdfsdf()`. Perhaps you haven't used static typing so aren't familiar with the kinds of bugs it can prevent?
  - mixmastamyk 3y ago
    Doctor, it hurts when I punch myself in the face. I need something to prevent that. I’m talking about realistic errors, not theoretical ones that would crash at first run. You have one test, right? Run the code once before deploying? I thought so. In which case, pyflakes and a few tests find a great majority (not all) of errors devs actually have.
    - IshKebab 3y ago
      > pyflakes and a few tests find a great majority (not all) of errors devs actually have. No they don't. First of all people are really bad at writing tests. Secondly, writing tests sucks; I would much rather write static type annotations than tedious type checking tests: you know when to stop and you get the other benefits of static types like making the code easier to read and navigate. Every piece of code I've added static typing to has revealed bugs. One we later hit in production (because the author was stupidly against static typing so I gave up trying to help him). That bug was simply calling a method that didn't even exist. It was in a code path that wasn't tested, despite having some tests. But I can see you're from the school of "I don't make mistakes" and convincing you otherwise is about as effective as trying to persuade Christians there isn't a god.

yen223 3y ago

I agree. Type-checking in general is good. However, Python's type-checking mechanisms are bad. The syntax for adding types is very obviously bolted on, they miss basic type errors all the time, and third-party libraries often miss type annotations anyway. Python is fundamentally a duck-typed language, and that's how you should use it. If type-checking is important to you, use a language that is designed for it.

roland35 3y ago
Eh it's either Python or C++ with ROS, and Python is much easier to work with. Adding type checks to method arguments isn't much different than doing it in Rust, and makes life much easier with anything larger a tiny program. If there is anything complicated, you can either make a quick generic type (TypeVar) or even just throw in an Any type! I had to do that recently with a function that handled different ROS services, which apparently do not share any base class.