27 ms·

Well, there's also type hints that so far we haven't added to "What's New" :) https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-048

Well, there's also type hints that so far we haven't added to "What's New" :) https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/

benhoyt 11y ago
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/140654.html https://mail.python.org/pipermail/python-dev/2015-July/14065...
Animats 11y ago
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.
- hyperpape 11y ago
  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.
  - gsnedders 11y ago
    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.
    - techdragon 11y ago
      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.
  - rudolf0 11y ago
    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.
- rpcope1 11y ago
  >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....
  - andrepd 11y ago
    >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.
    - rpcope1 11y ago
      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. [1] http://docs.scipy.org/doc/numpy-dev/f2py/getting-started.html http://docs.scipy.org/doc/numpy-dev/f2py/getting-started.htm... [2] http://pymca.sourceforge.net/ http://pymca.sourceforge.net/ Also: http://www.quora.com/How-did-Python-dominate-scientific-computing http://www.quora.com/How-did-Python-dominate-scientific-comp... http://programmers.stackexchange.com/questions/138643/why-is-python-used-for-high-performance-scientific-computing-but-ruby-isnt http://programmers.stackexchange.com/questions/138643/why-is... Finally as a Physics person, you might also like the coursework for this (I certainly enjoyed the course): http://pages.physics.cornell.edu/~myers/teaching/ComputationalMethods/ http://pages.physics.cornell.edu/~myers/teaching/Computation...
- silverpikezero 11y ago
  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.
  - jjtheblunt 11y ago
    I'd say the comment was less inflammatory than perhaps justified.
- kevin_thibedeau 11y ago
  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.
- zeckalpha 11y ago
  That's not wholly true. While stub files are proposed, they're not required to use this feature.
Ultimatt 11y ago
Perl 6 has full gradual typing YAY https://www.youtube.com/watch?v=id4pDstMu1s https://www.youtube.com/watch?v=id4pDstMu1s

Well, there's also type hints that so far we haven't added to "What's New" :) https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/

benhoyt 11y ago

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/140654.html https://mail.python.org/pipermail/python-dev/2015-July/14065...

Animats 11y ago

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.

hyperpape 11y ago
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.
- gsnedders 11y ago
  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.
  - techdragon 11y ago
    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.
- rudolf0 11y ago
  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.
rpcope1 11y ago
>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....
- andrepd 11y ago
  >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.
  - rpcope1 11y ago
    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. [1] http://docs.scipy.org/doc/numpy-dev/f2py/getting-started.html http://docs.scipy.org/doc/numpy-dev/f2py/getting-started.htm... [2] http://pymca.sourceforge.net/ http://pymca.sourceforge.net/ Also: http://www.quora.com/How-did-Python-dominate-scientific-computing http://www.quora.com/How-did-Python-dominate-scientific-comp... http://programmers.stackexchange.com/questions/138643/why-is-python-used-for-high-performance-scientific-computing-but-ruby-isnt http://programmers.stackexchange.com/questions/138643/why-is... Finally as a Physics person, you might also like the coursework for this (I certainly enjoyed the course): http://pages.physics.cornell.edu/~myers/teaching/ComputationalMethods/ http://pages.physics.cornell.edu/~myers/teaching/Computation...
silverpikezero 11y ago
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.
- jjtheblunt 11y ago
  I'd say the comment was less inflammatory than perhaps justified.
kevin_thibedeau 11y ago
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.
zeckalpha 11y ago
That's not wholly true. While stub files are proposed, they're not required to use this feature.

Ultimatt 11y ago

Perl 6 has full gradual typing YAY https://www.youtube.com/watch?v=id4pDstMu1s https://www.youtube.com/watch?v=id4pDstMu1s