Python doesn't have a transpilation stage like TypeScript, which gives JS a sort of compile-time check that forces the developer to fix type errors. Python type hints can just be ignored.
"TypeScript is better because I'm required to run the transplier"
If you believe that type checking is necessary, you won't have problem running mypy.
Also TypeScript has a transplier, because there was no other option, browsers use JavaScript and don't understand TypeScript so the conversion is necessary. Maybe that won't be needed in the future, but it is needed now.
A lot of people don't only work on their own code. They have dependencies, they have coworkers, they have to work on code they wrote nine months ago. So it's not "I need to be forced to use the type checker," it's "everybody needs to be forced to use the type checker."
I have no idea what argument/point you're trying to make.
The TypeScript workflows happens to include this amazing process where auto-complete and other features work on non-TS libraries/code for no other reason than someone decided to take the time to provide type information on something that otherwise wouldn't have it. In a repository/workflow that is easy for any developer to easily tap into.
This is amazing.
How did you jump to "TS is better" or some silly thing like that?
TS build pipelines almost by default don't let developers build/commit code if a type definition isn't followed. This is a HUGE workflow step that isn't common with Python and type hinting. It makes a big difference. There is no Python equivalent of MyPy "headers" or type information for countless third-party libraries.
I use flake8/Black as part of my Python development experience, but it still doesn't compare to what the TS community has been able to pull off.
> The TypeScript workflows happens to include this amazing process where auto-complete and other features work on non-TS libraries/code for no other reason than someone decided to take the time to provide type information on something that otherwise wouldn't have it. In a repository/workflow that is easy for any developer to easily tap into.
> This is amazing.
The same thing I observe in Python and PyCharm.
> TS build pipelines almost by default don't let developers build/commit code if a type definition isn't followed. This is a HUGE workflow step that isn't common with Python and type hinting. It makes a big difference. There is no Python equivalent of MyPy "headers" or type information for countless third-party libraries.
I don't think I understand, could you give me an example. I don't see how types can work if no type information is provided.
PyCharm and JS (Babel) are only similar in that they turn text source code into AST's
With Python + PyCharm, the default mode is to allow developers to exclude and ignore types and code will still run, no matter how many orange/red markers are in PyCharms gutter. To change that mode, you need to consciously decide to add something to your workflow that will impede you if something is wrong e.g. git hooks to run linters, flake8, black etc.
With TypeScript, the default mode is to stop the developer in their tracks - the TS compiler will fail, and you can't run code (generated JS) that doesn't exist. Types are not optional, unless you make them explicitly so (which is still providing a type).
> I don't see how types can work if no type information is provided.
TS can still import native JS code... given that it has a TypeScript declaration file [0]. Many popular libraries offer one now, but many more do not. The community came together and created DefinitelyTyped [1], where 10k contributors have made 65k commits to provide TS declaration files for over 5,200 libraries spanning countless versions/releases.
This means a TS developer can import JS code that doesn't have 1st-party TS support, but does have 3rd-party through DefinitelyTyped.
> "TypeScript is better because I'm required to run the transplier"
You've missed the point entirely. The whole point is that TypeScript benefits from compile-time type checking, which is performed by TypeScript's transpiler.
Python's type annotations are just that: annotations, which can/have no effect.
When you have a compiler/transpiler the process typically is done in two steps, running a type checker on the code and then the actual compilation (which could be split into more steps). When you run mypy, you're doing the first step.
The types you define in TypeScript you similarly define in Pythin, they just call them annotations, and there's an option to reference them at runtime, but mypy doesn't work at runtime (perhaps that's where the confusion is from?)
