What’s New In Python 3.3
docs.python.org
docs.python.org
From what me and my coworkers have discussed we are basically all waiting on Django to get Python 3.x adoption. I've tried submitting multiple patches for this and helping Django as much as possible but they don't seem to want outside help.
Come on Django, come on, a lot of us are waiting for you.
The problem is and continues to be the social and community issue of gracefully deprecating our way out of Python 2.x, which we're basically doing at a rate of one Python version per Django release. All the patches in the world can't really make this process go faster :)
The situation hasn't changed. If you want to work with Django on Python 3, go ahead; the code's right there for you. We need the help: it's going to take a lot of burn-in to make sure we get everything right.
If you're waiting for it to hit trunk, fair enough I guess (though it's a purely arbitrary decision on your part; the only difference between the branch and what'll hit trunk is the URL). That should happen shortly after 1.4 ships, so quite soon now.
My rule of thumb is write new stuff in Python 3, keep old stuff on Python 2 unless I have to rewrite it for some reason anyway.
Upgrading just to upgrade seems like developer problem more than a technical problem.
[1] http://blog.python.org/2011/07/python-launcher-for-windows_1...
I simply like to keep myself up with the market/community, when I release new software I try and make sure I'm not releasing something on a platform that will be dead in a month.
You're confusing Fedora and Red Hat. Fedora is generally very cutting edge and has been shipping with 2.7 for quite a while now, Red Hat is far more conservative and was, at least up until the latest release, shipping with 2.4
Fedora 16 (the latest) ships with Python 2.7. Python3 is available in the yum repositories.
Distros aren't holding Python3 adoption back, it's apps and libraries.
As far as I can see, they're shipping both 2.7.2 and 3.2.2: http://pkgs.fedoraproject.org/gitweb/?p=python.git
The biggest problem I have is that Python 2 works "good enough" and upgrading to Python 3 does not have many benefits, other than lots of work and slower performance. I guess a lot of people feel the same way, hence the slow or non existing adoption of Python 3. I guess Python 3 might end up as Perl 6 if this continues since we keep investing time on Python 2.x libraries and features.
What we need is a reason to upgrade and the killer feature of Python 3 could be performance. I would upgrade to Python 3 in a instance if it offered a lot better performance than Python 2.
How do we achieve better performance? Adopt PyPy as the reference implementation for Python 3 and all future references. Making PyPy a centerpiece of Python 3+ would probably mean it would mature faster.
PyPy is focused right now on Python 2.X, but I would rather see it focus on the future of Python and being a killer feature of Python 3+.
For example, the performance of Python 3.0 was slow on I/O operations. The reason was because the I/O modules were written in pure-python in order to get the ball rolling. This wasn't a bug. However, the code was eventually ported to C in 3.1 and unsurprisingly the performance improved: http://www.gtsystem.eu/blog/2009/08/improved-performance-of-...
And that's an old post from 2009! The performance is much better today.
Features they're releasing in this new version include zero-copy in os.copyfile() which is totally sweet. No user-space buffers involved in transferring bytes from a file to a socket. This should speed up such operations well past what any version of python 2.x is capable of.
There isn't a feature in Python 3 that is not substantially better than 2.x -- they're fixing all the fiddly bits and producing a much better language. There is no feature they can create which will open the dam to a flood of porting projects. The reason is that the problem is a social one.
An honest-to-goodness effort to port the large libraries requires a plan to support the existing 2.x versions alongside the 3.x versions so that the people who are still running applications built on the old versions will still work. This requires extra effort that is difficult to acquire in open source projects let alone commercial ones.
Even if the Python 3 devs added a feature that materialized ponies out of thin air there would still be projects running the 2.x code.
It's been 3+ years since Python 3.0 has been released, and, while I agree that there's no "substantiated evidence" for its demise, some of us who witnessed the whole Zope2 to Zope3 "transition" know that in the end "evidence" doesn't count at all. What count are actual smart people, lots of them preferably, building cool and useful things with the new tool.
If you're ever going to make the port, you have to decide to do it and make the effort. Nothing the Python 3 devs release will ever convince you to port otherwise.
Pypy is focussed on supporting 3.x. There are two major initiatives going now, one of which is numpy support and the other is Python 3 support.
People aren't "investing time on Python 2.x libraries and features". Python 2 is going to just receive security and bug fixes and all new work is on Python 3. Major libraries are currently supporting Python 3, including almost all of the widely used ones (numpy, scipy, sqlalchemy, virtualenv, etc). The ones that aren't, are being ported (django, twisted).
Overall, the tone and information in your post is quite outdated. Your sentiments were shared by a lot of people circa Python 3.1, but now it is 2012 and the Python ecosystem has mostly got a handle on how to straddle two versions, after being help up for a bit by discovering that the initial "lib2to3" approach wasn't the best solution for many projects.
http://morepypy.blogspot.com/2012/03/py3k-status-update-2.ht...
At least Perl 6 is aiming for some amazing advances that will trade off quite well (if it is ever delivered) against breaking compatibility with Perl5.
Py3 broke compatibility (at least at the extension layer) for what exactly...now I can say print() instead of print ""? What a joke.
Some of these things could be back-ported to Python 2.7 as libraries but I'd much rather see a bigger push to move onto Python 3 instead.
I look forward to even more Python 3 awesomeness in the future. Each release is a compelling reason to start porting.
Libraries aren't really ready for 3.x series and developing on 2.x series is not making any sense as if 2.x ultimately goes away then migration effort on that is not worth.
At the same time 3.x ecosystem is not ready either.
That is, if you can use Python 3, you should: it's the future of the language, and it feels it. I find Python 3 significantly more pleasant than Python 2; nearly all the bits that annoy me about Python are fixed in 3. Python 3 is cleaner, the standard library is de-crufted and easier to navigate, and (most important to me) handling unicode doesn't suck.
However, as others in this thread note, significant parts of the Python ecosystem haven't finished porting yet (Django, Twisted, yada yada yada). If you rely on one of those things, then stick with Python 2. If that code lives fo a long time you will have to face a porting effort later on, but that's improving somewhat as the community discovers new techniques and creates new tools.
It's too bad that django, zope and werkzeug (flask) aren't there yet. I understand that a lot of people on this site use django and so these discussions are always dominated by people complaining that they can't use Python 3 because their dependencies (django) aren't available.
But the Python community is much bigger than django and today most of the rest of the ecosystem is ready and working fine. The parts that aren't, are getting there rapidly.
http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python...
Note that he advises leaving print statement be; it's more familiar in 2.x land, editors often are confused with print function syntax highlighting, and it's easily handled by 2to3.
Having ported programs that accept multiple types of strings from Py2 to Py3, Py3 is DRAMATICALLY easier to work with here.
The biggest downside is that in order to upgrade from Py2->3, I needed to patch half a dozen different libs.
The migration was always expected to be a long-term thing, and so far has been pretty pain-free imho. But then I haven't written any code that doesn't run in 3.x since 2010, finding that 3 increasingly meets my deps and is more enjoyable and productive to code in, and when I do need to support 2 that the common subset of 2.7 and 3 is large enough to do many things.
The list gets longer of course if you fairly add all the things eventually backported to 2.7, e.g. set literals and comprehensions.
So, does 2.x work? Sure. Is 3 better? Yup. If I get to pick one, I pick 3.
As just one example, could Guido not have made the print statement a function through the simple mechanism of:
from __future__ import printfn
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#perfo...
[2] https://github.com/kripken/emscripten/wiki
[3] http://pyjs.org/
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.
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
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-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.
... 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).
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-o...
Looks like we need another benchmark. Does anyone have the Python 2 code from the Shootout? It seems to have been removed so that you can no longer compare Python 3 to Python 2 directly.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
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).
Ahhhahaha, ahhhahahahahahahahahaha! Good lord I wish this was true!
Jacob, there look like about 20 or more programmers on that page. At even $100k per programmer, isn't that about $2.4 million? And isn't the number much more than that given that you are among the most skilled engineers?
* "Even 100k" implies that you think a six figure salary is reasonable for programmers. This is true in some rarefied echo chambers likethe Bay Area where programmer salaries are overinflated, but it's far from a universal The majority of our committers don't live near San Francisco. Actually, I think most live outside the US these days. I don't believe the median salary of a Django committers is 100k -- though for my fellow committers' sake I hope I'm wrong :)
* I only wish "being a core Django committer" was some magic "Get a Great Job Paying Six Figures Card". No good hiring manager assumes that "has a Django commit bit" translates to "among the most skilled engineers"; I only wish I could pull down "much more than" 100k based solely on my Django status. It's certainly a good time to be a Django dev, but while being contributor might help you get your foot in the door, it won't land you a salary increase over your peers.
* None of us get paid to work on Django anywhere close to full time. We get paid to do other things; we're lucky if we get a few hours a week to hack on Django as a side project. This again shows that our value in the salary marketplace isn't linked to our willingness to volunteer time to Django.
* Finally, this whole silly exercise assumes it would take "a year or two" of ALL of our time to get Django onto Python 3. That's laughable: it's mostly done already with perhaps a couple of man-months of activity. There's nowhere near 20 programmer-years worth of work; suggesting such is simply insane. Toss me that 100k you're bandying about so easily and I'll have it done by May :)
Considering merge with trunk will probably be done shortly after 1.4 I don't think he'll be getting his money's worth ;)
Do these documents really need to come out and spell it out for you? If you were to read what the document is telling you, you could probably figure it out.
> That one is easy.
Your original comment was about the print statement changes costing so much time and money, but now they are about the entirety of Django and NumPy. Yeah, it certainly costs money for a big project like Django to port (and people have completed it in their free-time), but print function/statement changes are trivial and do not cost on the order of billions of dollars.