Yes. I'm not entirely sure why this was posted now, as it's a couple of months from 3.5's release date yet, and What's New is not up to date. On python-dev, David Mertz just volunteered to write/update this "What's New" page, somewhat sponsored by the company he works for, Continuum: https://mail.python.org/pipermail/python-dev/2015-July/14065...
Type hints are not Pythonic. The syntax is ugly. It adds "stub files", like C's ".h" files, something newer languages such as Go and Rust don't need. Some of the proposed syntax is even in comments, because it didn't fit the language. But something had to be done to meet competition.
The problem Python faces is that Python's Little Tin God painted the language into a corner. He insisted for years that everything in Python had to be fully dynamic.
This limited performance.
Then came competition in Python's space. Go came along, Javascript got traction on the server, and Python faced a real threat. Both of those can beat Python on performance, sometimes by huge margins, and they're useable by Python-type programmers used to the freedoms of scripting languages.
The Python 3 debacle had already thrown the Python community into disarray - most of the production work is still on Python 2, which was supposed to be abandoned but refused to die because the cost of conversion was much higher than expected. Meanwhile, Python 3 takeup was far less than expected; numbers like 10-20% come from downloads, and production use is probably less. Another incompatible change in the syntax would be rejected by the market. An incompatible change to a "typed Python" wouldn't fly.
So we get PEP 484, which is ugly but might help Python survive. Might.
Your comment is grossly overstating the issue, and unnecessarily inflammatory. I have reviewed the type hints syntax, and it's not so bad. It's doubtful that anything nicer can be implemented on top of what you have clearly pointed out is a dynamically typed language.
Your criticism of Python being dynamically typed is also misguided. There are many benefits of having a dynamically typed language, which I won't bother to enumerate here since this subject gets beaten to death regularly on HN. It is a good choice to make this design decision up front and honor it as the language grows. Guido is not a moron; he knew there would be performance implications. Nobody today chooses Python for it's native performance anyways (although Cython and PyPi have made great strides for common cases).
The value of Python is not in performance, it's in the language simplicity, large ecosystem, and highly developed libraries. There are some disciplines such as machine learning and quantitative finance which are all but predicated upon Python, with excellent results. Comparisons to Go and JS are incongruous; those languages have other benefits which would make them good choices if things like concurrency (Go) and very high level abstractions (JS) are important.
The Python 3 transition was indeed rough, but in no way is it a "debacle". The community is not in "disarray"; that's absurd. The transition to 3 will happen eventually, and indeed this lethargy was caused by deliberate breakage in language features. Maybe not the best decision in hindsight, but far from this cataclysmic fantasy you seem to be depicting.
>So we get PEP 484, which is ugly but might help Python survive. Might.
This seems really hyperbolic. I'm not sure Go really competes in the same space as Python; also Python is so well entrenched as the successor to Fortran in the scientific computing space, that this would seem to guarantee continued relevance far into the future. It's probably like a lot of things, it may not be as sexy or break neck fast (though PyPy is staged to change that, and maybe we can also feasible get a non-sucky version of IronPython or Jython), but it's pretty much everywhere now, kind of like Perl, C, PHP, Java....
>also Python is so well entrenched as the successor to Fortran in the scientific computing space
Uhhh... no. FORTRAN is literally the fastest programming language in existence. Maybe Python is good for prototyping or pre/post-processing some data, but with a performance hit in the 100x order of magnitude, you won't run Python scripts for the bulk of any serious scientific computing project.
I think numpy and scipy[1] beg to differ. You should go look at what's actually available in terms of scientific computing on Python, as I think you might actually learn something (hint: numpy is really a bunch of Python wrappers over FORTRAN routines, if you look at the source code). Having been a PhD student in Physics, in particular (at an Ivy League university, nonetheless), I can tell you that the majority of new code we were writing was Python, and since I've left, it's probably gotten more so. A good example of Python in physics, is PyMCA[2]. Python is really poised to also (thank god) reduce the marketshare of Matlab.
another thing to consider is f2py, which allows calls to Fortran subroutines from Python. in my experience, it was faster than numpy, but you have to suffer from writing Fortran.
I got inconsistent results when using Numba. when it worked well, it was way faster than Numpy, but sometimes it was slower. I wasn't able to figure out how to do AOT compilation, so I just went with f2py. if Numba has AOT compilation, I'd definitely use that over f2py though.
AOT compilation is in the works. Also you might have been using features that numba didn't support yet. They just added more numpy ops, array allocation and vector ops, so your code might be working now.
Most scientific computing is not "serious". My past couple papers, for example, have been mostly Python analysis of geospatial data. I use Python because it's easy to integrate with Postgres/PostGIS, and the numerical code provided by Numpy is fast enough. (I drop down into Cython when needed.) The algorithms I need to run aren't hugely intensive -- at most, something might take an hour to run, and most of my simulations take just a minute or two.
I don't need raw speed. I need development speed so I can easily iron out bugs and try new methods. My colleagues develop in R for the same reason.
I think it depends what you count as scientific computing. I'm an engineer at an industrial plant and like you for offline non intensive stuff when I have to knock up a prototype fast I use SAS mostly because it has good integration with databases and I can crank out code very fast using it.
My housemate is a Math/Stats person he works in finance and uses R for much the same reasons.
Maybe Python is useful but it would have to offer me something compelling to make me switch over.
Maybe not pure Python, but one of the best features of CPython is easy interoperability with C or Fortran. Python is the glue for hard-to-use but blazing fast numerical libraries. You can also write very fast code in Cython, which has basically the same syntax as Python.
Python is used in a vast amount of scientific codes. I do a very significant chunk of my work in Python. And heck, I reach to C++ to do the pre/post processing, believe it or not, the inverse of what you suspected.
As far as I know type hints don't affect Python's performance, because they're optional and not yet used by the runtime.
In any case, JavaScript is dynamically/unityped, so its performance is unlikely to provide a reason for type annotations. The real problem here is that PyPy is still maturing, and can't be used by many people because of legacy C extensions.
An they're unlikely ever to be used by the runtime, because what hints there are are far too vague. Saying something is class X is useless when you don't know what attributes that class has (because they can be dynamically added and removed) nor what types those attributes are.
The level if information modern Python tools like those in PyCharm and JEDI can reason through to and discover about runtime behaviour is actually pretty impressive. I don't think it's going to pose a huge challenge for these kinds if tools to find. Dealing with ambiguous cases is a UI problem, too much info, not enough space.
They don't affect performance, but I have to agree they really don't look nice to read or write, which is unfortunately the antithesis of Python's philosophy.
How's this for a debacle: I just ported a 2.6 app to 3 and it only required fixing one line due to a change in library behavior. 2to3 took care of the rest.
https://www.python.org/dev/peps/pep-0484/