"Wall of Shame," sounds harsh. However I don't think it's entirely inappropriate. The premise is that it has been two years since py3k has been release and the community has little to show for it. One would think two whole years would be enough time to port a library. Especially if most of the fundamental challenges of doing so are matters of syntax (not in all cases I'm sure) and changing some names.<p>OTOH, maybe the community still refuses to switch? Maybe py3k is viewed as "that bad," that no one wants to bother with it?<p>FWIW, py3k is quite fast now and the language "enhancements" do make a significant difference. I actually quite like it now that my primary OS, Arch Linux, gave me the boot and made py3 the default interpreter. Many of my projects are still in py2.7, but I have been working on converting them. Sometimes I get lucky and all I need to do is run 2to3!
The equivalent for Ruby 1.9 is here:<p><a href="http://isitruby19.com" rel="nofollow">http://isitruby19.com</a><p>And there's a version that shows rails3 compatibility amongst other things here:<p><a href="http://railsplugins.org" rel="nofollow">http://railsplugins.org</a>
Funny to see zope.interface on that list. I remember back in 2005, when Zope 3 had just been launched, about how everyone who mattered in the Zope world would say things like "only stupid, retrograde people won't switch to Zope3". I guess the stupid people won, because 6 years on Zope is like the Cobol of Python web frameworks. I just hope the same thing won't happen to Python itself.
I've been doing a ton of Python work lately. Frankly, in my experience, Python 3 is more of a pain to develop with, primarily due to two factors:<p>* Encoding specifications required.<p>* maps/reduces returning iterators objects instead of a list. Having to call list() on anything I map is just a pain.<p>I don't plan to switch to Python 3 until a compelling reason shows up. 2.7 works great for what I do.<p>The real story here is how Python 3 appears to be a largely unwanted improvement, IMO.
This is a really good list for people who want to get involved in a Python project. I only wish it were bigger and it would contain smaller projects as well.<p>DecoratorTools shouldn't really be on that list though, since it doesn't make any sense for py3.
"Wall of Shame"? Really?<p>As someone who's project appears on this list (and in the WRONG color) all I can say is that I don't think anyone is trying to dis Python 3.x. Support will come when a critical mass of developers are using 3.x. I know it's kind of a chicken and egg problem but this seems to be saying that it's the package developer's fault and I don't really think that's fair or true.
Pretty much inaccurate data. For example many project release under a new "3k" name, and leave the old ones. One of those is a backport of a stdlib module (multiprocessing), etc. So, it's bad data, and misleading, but I admire the idea.
I think a large part of the problem is that there aren't strong incentives to switch to Python 3, or at least that was the case when it first came out, and first impressions tend to matter. To me, as a user, it looked like "slower and none of my libraries will work."<p>A better way to sell python 3 should be to highlight python 2's pain points, and show why 3 is better. If they were to show a significant performance gain over Python 2.x, or some sort of killer new feature (ie, get rid of "self" everywhere) I suspect python 3 would get a lot more traction. As it is, Python 2 as a language works just fine for me, and most of what I want (a better interpreter) are being addressed by the PyPy project.
At first I was going to say that we need some sort of dependency graph to focus on what needs to be ported first. As a Plone developer, I see lots of stuff down the stack that needs to be done before Plone could move to Python 3. However, simply ranking based on number of downloads seems to do a pretty good prioritization.<p>Out of the first 10 packages that haven't been ported to Python 3, I think nearly all are needed for Plone. (Although things like virtualenv are not a requirement for Plone, they are widely used in Plone development)
I am currently doing a similar sort of website, but trying to limit it to popular projects only. Also trying to group together a lot of the python 3 related articles and porting tips.<p>My current research can be found here: <a href="http://goo.gl/SCImr" rel="nofollow">http://goo.gl/SCImr</a><p>Any corrections, or ideas for what can be on the site would be appreciated.
It will be interesting to see how Guido et al will judge the py3k transition-strategy in hindsight and whether they will repeat it or move back to a more traditional, incremental development model.
There's a lot of improvements in 3, but I'm sad to say I'm really hung up on print (and that's why I'm still using 2.x).<p>Eventually, I guess. If I have to.
The real issue is that for both developers and library maintainers, moving to Python3 entails a lot of aggravation for a comparatively small net benefit.