5 ms·

Unfortunately, Python 3 is the new Perl 6. It offers reduced performance[1], changes some of the hardest-to-debug parts of the language (like Unicode), and capr

Unfortunately, Python 3 is the new Perl 6. It offers reduced performance[1], changes some of the hardest-to-debug parts of the language (like Unicode), and capriciously introduces backwards incompatibilities. For no obvious gain! As just one example, could Guido not have made the print statement a function through the simple mechanism of: from __future__ import printfn Then new code could use printfn and old code could use print, and all would be well. But instead, literally billions of dollars will be wasted changing every single print keyword statement to a print function invocation. Sure, you can use 2to3. But the tool is that worst of all worlds, a compiler that doesn't really work 100% and actually reduces the performance of your code in the compilation process. For those who do not want to waste their time on this port, Python 3 is going to accelerate the move towards full stack JS just like Perl 6 accelerated the move towards Python/Ruby. This JS stack will be MongoDB + node + Backbone/coffeescript or some similar permutation. After all, if you are going to literally have to recompile your language with 2to3 and deal with all the edge cases, why not go whole hog with something like emscripten[2] or a souped-up pyjamas[3] to convert your legacy Python 2 code to JS? Then people just need to start porting C/C++ numerical libraries over to V8 through something like v8-juice[4] and we will have all the missing pieces. [1] http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo... [2] https://github.com/kripken/emscripten/wiki https://github.com/kripken/emscripten/wiki [3] http://pyjs.org/ http://pyjs.org/ [4] http://code.google.com/p/v8-juice/ http://code.google.com/p/v8-juice/

briancurtin 15y ago
> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo... The thread is about 3.3, so you link to a 3.0.1 release note? That is three years old. > literally billions of dollars will be wasted changing every single print keyword statement to a print function I'd love to see the math on this, especially because I did it in a matter of minutes across all of my code.
- ramanujan 15y ago
  > 3 years old I'm pretty sure they'd have announced it if Python 3 ever got faster than Python 2. But this is not mentioned in the 3.1, 3.2, or 3.3 notes on performance: http://docs.python.org/dev/whatsnew/3.1.html#optimizations http://docs.python.org/dev/whatsnew/3.2.html#optimizations http://docs.python.org/dev/whatsnew/3.3.html#optimizations > see the math That one is easy. The Python 3 conversion is a serious project for core devs at Django and Numpy. Check out their mailing lists about what this takes/took. http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-scipy-migrate-to.html http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-sc... While the above procedure of using the 2to3 tool works relatively for pure Python code, there is no automatic conversion tool for extension code. NumPy is mostly written in C and makes extensive use of the Python C-API. So converting NumPy will require much more than running the 2to3 tool. https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3 https://docs.djangoproject.com/en/dev/faq/install/#can-i-use... ... it will be a while before most Python software catches up and is able to run on Python 3.0. For larger Python- based software like Django, the transition is expected to take at least a year or two (since it involves dropping support for older Python releases and so must be done gradually). A "year or two" of the core Django team's time is easily several million bucks. Multiply by the Python codebases of every company on this list [1], and everyone on github, and every egg out there, and we are talking billions for the conversion. [1] http://wiki.python.org/moin/OrganizationsUsingPython http://wiki.python.org/moin/OrganizationsUsingPython
  - ldite 15y ago
    > I'm pretty sure they'd have announced it if Python 3 ever got faster than Python 2. According to this blog post, 3.2 performance now exceeds 2.6 and 2.7, using the same pystone benchmark that the 3.0 release notes refer to: http://www.levigross.com/post/2340736877/pystone-benchmark-on-2-6-2-7-3-2 http://www.levigross.com/post/2340736877/pystone-benchmark-o...
    - sb 15y ago
      Supporting your statement: I am positive that Python 3 could be a lot faster than Python 2. If people are interested in what's possible, they should follow the corresponding mailing list (python-dev).

briancurtin 15y ago

> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo... The thread is about 3.3, so you link to a 3.0.1 release note? That is three years old. > literally billions of dollars will be wasted changing every single print keyword statement to a print function I'd love to see the math on this, especially because I did it in a matter of minutes across all of my code.

ramanujan 15y ago
> 3 years old I'm pretty sure they'd have announced it if Python 3 ever got faster than Python 2. But this is not mentioned in the 3.1, 3.2, or 3.3 notes on performance: http://docs.python.org/dev/whatsnew/3.1.html#optimizations http://docs.python.org/dev/whatsnew/3.2.html#optimizations http://docs.python.org/dev/whatsnew/3.3.html#optimizations > see the math That one is easy. The Python 3 conversion is a serious project for core devs at Django and Numpy. Check out their mailing lists about what this takes/took. http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-scipy-migrate-to.html http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-sc... While the above procedure of using the 2to3 tool works relatively for pure Python code, there is no automatic conversion tool for extension code. NumPy is mostly written in C and makes extensive use of the Python C-API. So converting NumPy will require much more than running the 2to3 tool. https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3 https://docs.djangoproject.com/en/dev/faq/install/#can-i-use... ... it will be a while before most Python software catches up and is able to run on Python 3.0. For larger Python- based software like Django, the transition is expected to take at least a year or two (since it involves dropping support for older Python releases and so must be done gradually). A "year or two" of the core Django team's time is easily several million bucks. Multiply by the Python codebases of every company on this list [1], and everyone on github, and every egg out there, and we are talking billions for the conversion. [1] http://wiki.python.org/moin/OrganizationsUsingPython http://wiki.python.org/moin/OrganizationsUsingPython
- ldite 15y ago
  > I'm pretty sure they'd have announced it if Python 3 ever got faster than Python 2. According to this blog post, 3.2 performance now exceeds 2.6 and 2.7, using the same pystone benchmark that the 3.0 release notes refer to: http://www.levigross.com/post/2340736877/pystone-benchmark-on-2-6-2-7-3-2 http://www.levigross.com/post/2340736877/pystone-benchmark-o...
  - sb 15y ago
    Supporting your statement: I am positive that Python 3 could be a lot faster than Python 2. If people are interested in what's possible, they should follow the corresponding mailing list (python-dev).