Python is strongly typed. It's also dynamically typed.
You can easily catch Python bugs analogously to how you would with a statically, manifestly typed language, using an IDE (or editor with plugins n- I like vim+syntastic), using a whole-program static analyzer (like pylint), using gradual typing (like mypy) and using automated tests.
I'm a big Python fan, but I can't stop looking enviously at Rust. It sounds pretty promising at catching bugs up front. I wish I could rewrite Python's innermost loops in Rust instead of Cython or C.
With appropriate software engineering tools, Python can do pretty well at catching bugs up front, but it sounds like Rust takes it to a whole other level: beyond pylint and mypy, beyond C++, beyond Java.
The earlier a bug is detected, the cheaper it is to fix, by orders of magnitude.
Agreed, but I'll point out that Python IDE's (or text editors with appropriate smarts like vim+syntastic), type inferencers (like pylint), gradual type systems (like mypy), and automated tests go a long way toward making it very cheap to catch Python bugs before deploying to test.
Combine that with the "fewer words per idea expressed" of Python, and you've got a winning combination.
Static typing is good for improving machine efficiency. It's also good for replacing the innermost loop of some Python programs.
Python's IDE's (PyCharm, vim+syntastic, emacs+I_bet_something_exists), type inference (pylint), gradual typing (mypy or pytype), and automated tests are more than adequate replacements for a static type system at catching bugs.
Compilation with a static type system need not be slow.
If anything, the analog with Python's implicit compile step (the interpreter itself), type inferencing (pylint), gradual typing (mypy), and automated tests is slower.
Developer time is more expensive than machine time in the modern world, and a VHLL like Python (plus a reasonable assortment of tools and techniques) is the best way to optimize developer time.
It's hobbled by a bad primary implementation though: The Glasgow Haskell Compiler. It's fast, it does impressive type inferencing, but the error messages from the compiler are rather poor.
Strong typing is pretty useful, but it isn't the opposite of dynamic typing.
Strong typing just means that your language has few to no implicit type conversions. A 100% strongly typed language wouldn't even implicitly promote an int to a float.
Java allows you to add a number to a string; this is an small example of weak typing.
Python is kind of similar with multiplying a string by an integer.
Assembler is untyped.
Perl is weakly typed.
Python is strongly, dynamically typed, and sometimes gradually typed.
Java is strongly, manifestly, statically typed.
Actually, I believe static languages exist in significant part because CPU time used to be more expensive than developer time. The manifest type checking is nice, but probably not their main reason for existence.
But Rust has this Python dev looking at it pretty enviously.
1) Using an IDE or Text Editor Plugin catches most bugs in Python before you save it to disk.
2) Using a whole-program static analyzer as part of your edit/"compile"/test cycle catches even more.
3) Using a gradual typing tool as part of your edit/"compile"/ttest cycle catches even more. Mypy, pytype can both do this, and I've heard PyCharm can too.
4) Using automated unit tests and automated system tests catches even more.
If you're using Python, you really should at least use the first 2, and I hope you use #3 and #4 as well.
Try these, then come back and relate your experiences with Python.
It's an error when you invoke mypy or pytype on the code, which should be done before you deploy to production, or even before you deploy to your test environment. These provide "gradual typing" for Python 3.x (nicely) and Python 2.x (kind of) - IOW, you can manifestly type some of your variables, but don't have to type all of them.
I converted one of my Python 3.x projects to use gradual typing with mypy. I manifestly typed my function/method formal parameters, and left most of the stuff inside them 100% dynamic. It seemed to work well.
This doesn't make your variables statically typed; the compiler knows nothing about the types you declare. It (mypy) enforces typing using an analysis tool that is separate from the compiler.
Slashdot Mirror
This is why I eschew streaming, and instead buy used dvd's.
Python is typed.
Python is pretty strongly typed, as is Java.
Tools like pylint and mypy can make Python practical for large projects.
Python is strongly typed. It's also dynamically typed.
You can easily catch Python bugs analogously to how you would with a statically, manifestly typed language, using an IDE (or editor with plugins n- I like vim+syntastic), using a whole-program static analyzer (like pylint), using gradual typing (like mypy) and using automated tests.
Actually, static analysis is pretty effective with python - see pylint.
Also, there's more than one JIT for Python - see Pypy and Numba, for examples.
Threading works fine on Jython and IronPython, but you're right that the threading in CPython is poor.
I'm a big Python fan, but I can't stop looking enviously at Rust. It sounds pretty promising at catching bugs up front. I wish I could rewrite Python's innermost loops in Rust instead of Cython or C.
With appropriate software engineering tools, Python can do pretty well at catching bugs up front, but it sounds like Rust takes it to a whole other level: beyond pylint and mypy, beyond C++, beyond Java.
Even a laissez faire bug checker like pyflakes can quickly and painlessly find most misspelled variable names in Python code.
I prefer pylint over pyflakes; pylint is more stringent. And I'm starting to like to like mypy, which adds gradual typing to Python.
Weakly typed languages are a little scary, and Untyped languages are even worse.
But Python is pretty strongly typed.
The earlier a bug is detected, the cheaper it is to fix, by orders of magnitude.
Agreed, but I'll point out that Python IDE's (or text editors with appropriate smarts like vim+syntastic), type inferencers (like pylint), gradual type systems (like mypy), and automated tests go a long way toward making it very cheap to catch Python bugs before deploying to test.
Combine that with the "fewer words per idea expressed" of Python, and you've got a winning combination.
Lines_of_code / number_of_bugs is roughly a constant across programming languages.
That's why programs written in VHLL's tend to have fewer bugs.
Static typing is good for improving machine efficiency. It's also good for replacing the innermost loop of some Python programs.
Python's IDE's (PyCharm, vim+syntastic, emacs+I_bet_something_exists), type inference (pylint), gradual typing (mypy or pytype), and automated tests are more than adequate replacements for a static type system at catching bugs.
Compilation with a static type system need not be slow.
If anything, the analog with Python's implicit compile step (the interpreter itself), type inferencing (pylint), gradual typing (mypy), and automated tests is slower.
Developer time is more expensive than machine time in the modern world, and a VHLL like Python (plus a reasonable assortment of tools and techniques) is the best way to optimize developer time.
Actually, I was forced to use PowerShell for about a year. It really was pretty poor - I compiled a list of the problems I found in it.
I suggested maybe using CPython or IronPython instead, but they wouldn't have it, because "nobody knows them".
LOL.
Static analyzers and gradual typing are available for Python.
Does't Haskell do this?
It's hobbled by a bad primary implementation though: The Glasgow Haskell Compiler. It's fast, it does impressive type inferencing, but the error messages from the compiler are rather poor.
A type inferencing tool for Python helps a lot with this. EG pylint.
Also, the gradual typing available in Python 3.x+mypy helps even more.
Strong typing is pretty useful, but it isn't the opposite of dynamic typing.
Strong typing just means that your language has few to no implicit type conversions. A 100% strongly typed language wouldn't even implicitly promote an int to a float.
Java allows you to add a number to a string; this is an small example of weak typing.
Python is kind of similar with multiplying a string by an integer.
Assembler is untyped.
Perl is weakly typed.
Python is strongly, dynamically typed, and sometimes gradually typed.
Java is strongly, manifestly, statically typed.
Actually, I believe static languages exist in significant part because CPU time used to be more expensive than developer time. The manifest type checking is nice, but probably not their main reason for existence.
But Rust has this Python dev looking at it pretty enviously.
More importantly why isn't there some gray scale on typing that I could slowly turn on as my program design matures? THis is what I would dearly love.
Python 3.x (and Python 2.x, sort of) has this now. It's called "gradual typing", and it's enforced by a 3rd party tool like mypy or pytype.
Python isn't weakly typed. It's dynamically typed. The 2 are not the same thing.
Not having to do type declarations is only part of what makes Python development fast. It's also a VHLL.
Remember that lines_of_code/bugs_in_code is roughly a constant, so the more concise a programming language is, the fewer bugs you tend to have in it.
1) Using an IDE or Text Editor Plugin catches most bugs in Python before you save it to disk.
2) Using a whole-program static analyzer as part of your edit/"compile"/test cycle catches even more.
3) Using a gradual typing tool as part of your edit/"compile"/ttest cycle catches even more. Mypy, pytype can both do this, and I've heard PyCharm can too.
4) Using automated unit tests and automated system tests catches even more.
If you're using Python, you really should at least use the first 2, and I hope you use #3 and #4 as well.
Try these, then come back and relate your experiences with Python.
Actually, this isn't an error when you run.
It's an error when you invoke mypy or pytype on the code, which should be done before you deploy to production, or even before you deploy to your test environment. These provide "gradual typing" for Python 3.x (nicely) and Python 2.x (kind of) - IOW, you can manifestly type some of your variables, but don't have to type all of them.
I converted one of my Python 3.x projects to use gradual typing with mypy. I manifestly typed my function/method formal parameters, and left most of the stuff inside them 100% dynamic. It seemed to work well.
This doesn't make your variables statically typed; the compiler knows nothing about the types you declare. It (mypy) enforces typing using an analysis tool that is separate from the compiler.
You need a static analyzer.
What editor are you using? vim+plugins can do this, and emacs probably can too.
.py to disk.
You probably should have automatic unit tests and automatic system tests, rather than manually retesting your code again and again.
pylint and pyflakes (both of which can be integrated easily into vim) can catch most variable name typos before you save your