Feature request! I wish this site would let you upload (or copy-paste) a requirements.txt file and then tell you what libraries you need to focus on fixing up for your project.
For those who missed the context of the title, the footer of the page:
> Note that this subdomain's called "python3wos" - once the status goes beyond 50%, the title of the site automatically becomes "Python 3 Wall of Superpowers". I kid you not.
Armin Ronacher's essay on the flaws of Python 3 seems to translate to his pet projects lagging on conversion. Which is a pity because they're great small, well-focussed pieces like werkzeug and Flask.
Agreed. There is an unofficial Python 3 port of Flask and Werkzeug, apparently[1]. And Armin says he started a “secret branch” a few months ago to explore adding Python 3 support[2], but no news since then.
The sense I get from the essay[3] is that Python 3.0/3.1 were quite flawed, but that more recent minor versions have been moving in the right direction. I'll admit I haven't personally done much more with Python 3.x than kick the tires a bit.
'Because as it stands, Python 3 is the XHTML of the programming language world. It's incompatible to what it tries to replace but does not offer much besides being more “correct”.'
Unlike Armin, I think that being more correct is worth some pain because it leads to offering much more in the future.
The alternative is PHP and its fractally bad design, where the legacy of accumulated, unfixed design flaws has made advancement almost impossible--which is why they have PHP 5.4 instead of PHP 6.0. You can add features within the context of those flaws, but at some point there are too many to execute the kind of overhaul you need.
It would be interesting to see someone fork PHP and offer a 'correct' version that's clean and sheds all the baggage.
It would be really useful if you could run both PHP 5.x and hypothetical PHP 6 code in the same interpreter process, so everyone wouldn't need to move over to the “more correct” version at once. I wonder just how hard that is to do. The approach doesn't seem to have been considered for Python 3, but, if possible, it would have saved lots of hassle.
Agreed, but I think they took a second approach that was also workable: Offer as much guidance and as many tools as possible (.e.g., 2to3, from __future__ import, etc), and then expect it to take years for the migration to occur. I don't know how possible it was to run both in the same interpretor process; I believe that it wasn't just because of the changes they were contemplating.
Lots of people like myself have been following our key libraries, but it's worth noting that, at this point, the migration seems both inevitable and not terribly difficult since 3.3 fixes most of the complaints about .0 and .1, and a lot of struggle to migrate has already been accomplished and offered lessons learned.
Many useful libs still aren't ported and some likely never will be (like Twisted). But more importantly, there is a vast amount of application code out there not ported. If you're working on a py2 project it's even hard to start new projects with py3, since you get no interoperation.
Breaking compatibility should have never been done without being able to run both py2 and py3 code in the same process.
It goes by the number of downloads from PyPI. I guess that's lower for matplotlib, because installing it from PyPI usually means compiling from source, which is a pain for something as complex as matplotlib. Many people probably get it from a binary package manager, or from an all-in-one Python distribution like EPD.
Yes, for my personal projects. It's much better than make. But unfortunately it needs to be installed while make is preinstalled on nearly all unixes. Now I always use qt creator for my personnal projects. It's excellent.
I don't think waf could be considered a fork of scons
> When Thomas Nagy decided that SCons's fundamental issues (most notably the poor scalability) were too complex and time-consuming to fix, he started a complete rewrite which he named Waf.
This is why the alternative build systems seem to never catch on. Everyone rolls their own, or forks, or rewrites instead of working together to improve one enough to "disrupt" autotools (though cmake comes close enough...). A sad but common problem in open source development.
Though, MySQL-python, South, and Fabric are still red. South and Fabric make django projects so much easier to deal with, especially once deployed. It will be interesting to see what happens when 1.5 is released. I presume they'll be released along with 1.5, or follow right on the heals of it?
Ruby 2.0 won't introduce as many incompatibilities, though. Something like the 2to3 tool wouldn't be needed. Most code is just expected to work as is.
I'm waiting for Python 3 to become de facto for newer/active libraries. Right now there's still a little standoffish demeanor about Python development for the future. I'd want to write in 3 but some important libraries are still backed up, so you're kinda forced to learn the idiosyncrasies of the porting scenario even though you'll most likely not need to know that 2 years from now when Python 3 is king.
Perhaps because the gains from Ruby 1.9 compared to 1.8 were a lot more enticing the community ported the libraries pretty swiftly. I don't see much hurry in the Python community, and some even talk about not porting at all.
