Just drag and drop the "requirements.txt" file over the website and that's it.
I sent the gist to the author of the app too (not the submitter) so perhaps he will include it in the code.
> 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.
The sense I get from the essay 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”.'
Ouch. Too close to the bone.
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.
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.
There are much more interesting things to port to (like PyPy).
Python 3.3 is a better Python.
And what "great cost" does 3 burdens us with anymore?
Since most of the lib porting has been done (it's been 5 years out already), there's not much cost to be beared, if any: you just get to use it.
Breaking compatibility should have never been done without being able to run both py2 and py3 code in the same process.
Now that scipy is supported, I'll start taking a look at python 3.
Take gunicorn for example, marked green. On the website it says:
Gunicorn requires Python 2.x >= 2.6. Python 3.x support is planned.
Edit: aha, that's probably the case. At the bottom of the page, it says:
> If a module is red though it supports python 3 it's because they don't have the "Programming Language :: Python :: 3" tag.
Tornado might be one of those packages people install from their distro's package or download from the parent website rather than via PyPi.
As for the background ... <shrugs>
Without it we'd most likely still be pulling our hair out trying to deal with make/cmake/qmake/what have you...
> 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.
Back to Ruby on Rails, I guess.
EDIT: Ruby 2.0 is taking a little while too--I kid because I love. <3 Python folks.
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?
Django 1.5 has experimental Python3 compatibility.
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.