4 ms·

I have 90 PRs to Mypy configured repos this year, across 10+ python repos which are a mix of services and background jobs. All of them have some mix of pyright/

by cbb330 3y ago

I have 90 PRs to Mypy configured repos this year, across 10+ python repos which are a mix of services and background jobs. All of them have some mix of pyright/jedi+ruff+black. I have implemented these tools either via CI or in my ide like experience in NVim. TLDR; BE WARNED. this basket of bandaids is NOT a replacement for a strongly typed language. I would NOT recommend Python to teams or for services. No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. This collection of bandaids is complex to maintain, upgrade, standardize, and has infinite edge cases where type annotation errors are just wrong. The worst part about this basket is that you get all of the above features for free and are REQUIRED with go via gopls and gofmt. Gopls "is the official Go language server developed by the Go team." good luck achieving parity of this in python. If you implement a service/app/anything production, use anything but a dynamically typed language like python.

linkdd 3y ago
> No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. Ah yes, because Python was never used in production ever, not at Google, not at Dropbox, not ever. The "static typing above all else" cargo cult is getting ridiculous.
- cbb330 3y ago
  It doesn't take an expert to notice that enforced types make a language more reliable in production, easier to debug, and faster to refactor. You should be horrified by Dropbox's blog post on python in production: https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python https://dropbox.tech/application/our-journey-to-type-checkin.... because this problem only existed and required $Ms of dollars to fix (even hiring the core team behind Mypy) because Python is being used instead of a typed language.
  - linkdd 3y ago
    I'm not saying that static typing has no value, it certainly does. But rejecting all dynamically typed language is a poor shortcut to take. Python, Ruby, Javascript, and others have a lot of success stories.
    - cbb330 3y ago
      I'm rejecting all dynamically typed languages *for production*. Where production means anything that needs to exist for a long time and is supported by a team. A litmus test for whether an app is production is if you actually need mypy, pyright, jedi, to effectively work on the repo. Python is great for single developer experience and going fast as a single developer. I use it every day, willingly, in jupyter notebooks. But at scale there are no success stories. You are zoomed in on the present success of "engineering miracles" and ignoring the big picture that the application would have moved faster if they had the foresight to choose a typed language. Hence, why i'm saying be warned on following the path of mypy+black+pyright+ruff+etc., since you will be doomed to patching on top of a fundamental flaw of the language. I highly recommend to avoid Python for production apps especially if it is your free will (and not a matter of refactoring or rewriting existing mistakes).
      - bjornasm 3y ago
        >But at scale there are no success stories. Do you believe this yourself?
        cbb330 3y ago
        yup! along the dimensions of feature velocity and developer experience with regard to cost. of course python/ruby/javascript have succeed in bringing value to the world in general -- but in this thread we're focusing on production reliability, debugging, refactoring. as we see, dropbox is proud to admit that they hired Mypy core developers and fund the project, but guess how much they spent on the mistake of using python? twitter, famously an advocate for Ruby, spent an ungodly amount of engineering to work around ruby, hit a wall, and switched to JVM. Just the fact that mypy and typescript exist and have exploded in adoption is proof that eng. teams very quickly hit a sand pit when using dynamic typed languages. Mypy being funded by dropbox, Typescript funded by microsoft, shows the level of investment needed to support these dynamic languages.

by cbb330 3y ago

linkdd 3y ago

> No amount of mypy, pydantic, pyright, ruff, black, can convert python into a production language. Ah yes, because Python was never used in production ever, not at Google, not at Dropbox, not ever. The "static typing above all else" cargo cult is getting ridiculous.

cbb330 3y ago
It doesn't take an expert to notice that enforced types make a language more reliable in production, easier to debug, and faster to refactor. You should be horrified by Dropbox's blog post on python in production: https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python https://dropbox.tech/application/our-journey-to-type-checkin.... because this problem only existed and required $Ms of dollars to fix (even hiring the core team behind Mypy) because Python is being used instead of a typed language.
- linkdd 3y ago
  I'm not saying that static typing has no value, it certainly does. But rejecting all dynamically typed language is a poor shortcut to take. Python, Ruby, Javascript, and others have a lot of success stories.
  - cbb330 3y ago
    I'm rejecting all dynamically typed languages *for production*. Where production means anything that needs to exist for a long time and is supported by a team. A litmus test for whether an app is production is if you actually need mypy, pyright, jedi, to effectively work on the repo. Python is great for single developer experience and going fast as a single developer. I use it every day, willingly, in jupyter notebooks. But at scale there are no success stories. You are zoomed in on the present success of "engineering miracles" and ignoring the big picture that the application would have moved faster if they had the foresight to choose a typed language. Hence, why i'm saying be warned on following the path of mypy+black+pyright+ruff+etc., since you will be doomed to patching on top of a fundamental flaw of the language. I highly recommend to avoid Python for production apps especially if it is your free will (and not a matter of refactoring or rewriting existing mistakes).
    - bjornasm 3y ago
      >But at scale there are no success stories. Do you believe this yourself?
      - cbb330 3y ago
        yup! along the dimensions of feature velocity and developer experience with regard to cost. of course python/ruby/javascript have succeed in bringing value to the world in general -- but in this thread we're focusing on production reliability, debugging, refactoring. as we see, dropbox is proud to admit that they hired Mypy core developers and fund the project, but guess how much they spent on the mistake of using python? twitter, famously an advocate for Ruby, spent an ungodly amount of engineering to work around ruby, hit a wall, and switched to JVM. Just the fact that mypy and typescript exist and have exploded in adoption is proof that eng. teams very quickly hit a sand pit when using dynamic typed languages. Mypy being funded by dropbox, Typescript funded by microsoft, shows the level of investment needed to support these dynamic languages.