571–580 of 581 posts
Earlier quoted context omitted.
I'm not saying you _can't_ do it. You could write production software in Bash if you really wanted to. I'm saying there are much better options.
I don't think writing your frontend in Rust instead of TypeScript or your computer vision pipeline in Java would be better at all. We rewrote our frontend in GHCJS (Haskell) at one point and it was a colossal waste of time.
Type hints in Python add a great amount of visual noise to the code, and I actively avoid them wherever possible. If static typing is a must, use a language where static typing is not an afterthought, and let Python be Python.
Would you rather deal with a little visual noise or a runtime exception that you could've caught before code got to production? For me it's about tradeoffs, and so far the tradeoff has been well worth it.
That said, I’m looking into the stubs.
Earlier quoted context omitted.
I don't think writing your frontend in Rust instead of TypeScript or your computer vision pipeline in Java would be better at all. We rewrote our frontend in GHCJS (Haskell) at one point and it was a colossal waste of time.
Where did I say write your front end in Rust or Haskell?
Earlier quoted context omitted.
By default, Mypy warns you if try to reassign a method of any object[1]. It will also warn you when you access non-existent attributes[2]. So if you have a variable typed as `object`, the only attributes you can manipulate without the type checker nagging are `__doc__`, `__dict__`, `__module__`, and `__annotations__`. Since there are very few reasons to ever reassign or manipulate these attributes on an instance, I t…
In my opinion the sheer volume of "close enough" choices is what ruins Python's type system. It's "close enough" to a usable type system that it's worth using, but it's full of so many edge cases and so many situations where they decided that it would be easier if they forced programmers to try and make reality match the type system rather than the type system match reality. No wonder a lot of people in the comments…
Earlier quoted context omitted.
In my opinion the sheer volume of "close enough" choices is what ruins Python's type system. It's "close enough" to a usable type system that it's worth using, but it's full of so many edge cases and so many situations where they decided that it would be easier if they forced programmers to try and make reality match the type system rather than the type system match reality. No wonder a lot of people in the comments…
I think they can get away with the "close enough" solutions since Python's type annotations don't have any runtime contracts by default. Might be off-putting to people who are more familiar with statically typed languages (though not always, in my experience).
You can live with the "close enough" if you're writing a brand new greenfield project and you prevent anyone from ever checking in code mypy doesn't like and also don't use any libraries that mypy doesn't like (and also don't make web requests to APIs that return dictionary data that mypy doesn't like)
Retrofitting an existing project however is like eating glass.
Earlier quoted context omitted.
> with none of the performance! If you care about micro-optimizations, the first one that overwhelms everything else is to not use Python. Anyway, if your types are onerous, you are using them wrong. Even more in a progressive type system where you always have the option of not using them or putting an "Any" there.
While most responders seem to have latched on to the pedantics of my “oop” comment - this is what my comment was intended to imply: why force the verbosity of static types on Python when statically typed (sic compiled) languages typically have much better runtime performance? the real answer i suspect is for quality of life/readability of code, but they are just “hints” afterall.
You are consistently showing you ignore how to use types and what they can do. Nobody is required to know about everything, but keep in mind that this is a lack from your part to understand it, not from the language.
Earlier quoted context omitted.
Where did I say write your front end in Rust or Haskell?
Okay, what's the great compiled alternative then?
WASM is obviously an option these days and well, but my understanding is that it's a long way from taking over.
Earlier quoted context omitted.
What I would need is a statically typed language that has first class primitives for working with untyped data ergonomically. I do want to be able to write a dynamically typed function or subsystem during the development phase, and „harden” with types once I’m sure I got the structure down. But the dynamic system should fit well into the language, and I should be able to easily and safely deal with untyped values and…
So… Typescript?
Earlier quoted context omitted.
Yep, I've used this pretty successfully, the ideal is to run it under realistic prod traffic over time to capture as many types as can flow into a given function, but a good set of unit/integration tests can also provide good coverage. And if you re-use the same type store (SQLite DB) across multiple instrumented runs, you can further improve it. https://github.com/Instagram/MonkeyType
RightTyper is much better in addition to running orders of magnitude faster. https://github.com/RightTyper/RightTyper (full disclosure, I am one of its authors).
Earlier quoted context omitted.
Yep, I've used this pretty successfully, the ideal is to run it under realistic prod traffic over time to capture as many types as can flow into a given function, but a good set of unit/integration tests can also provide good coverage. And if you re-use the same type store (SQLite DB) across multiple instrumented runs, you can further improve it. https://github.com/Instagram/MonkeyType
RightTyper is much better in addition to running orders of magnitude faster. https://github.com/RightTyper/RightTyper (full disclosure, I am one of its authors).