Hacker News new | comments | show | ask | jobs | submit login
Python 3 "Wall of Shame" Becomes "Wall of Superpowers" Today (python3wos.appspot.com)
120 points by llambda on Dec 12, 2012 | hide | past | web | favorite | 37 comments



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.


Here you go; just paste it in the Javascript Console: https://gist.github.com/4264971 (FF and Chrome tested)

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.


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.

1. https://github.com/puzzlet/flask

2. https://github.com/mitsuhiko/flask/issues/587

3. http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/


(A.R. essay, 2011.12:)

'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.


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.


Python 3 is still not useful. It fixes too little for too great a cost.

There are much more interesting things to port to (like PyPy).


To quote the Big Lebowski, "That's like, your opinion".

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.


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.


i think he said on twitter, he'll try to port to p3 during xmas vacation


Seems like Plone = 19 entries. That one fix would cut it down almost 40%.


Porting Zope 2 would probably equire about a dozen Jim Fultons...


I'm surprised that it doesn't list Matplotlib, which is widely popular and supports Python 3.


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.


Scipy is listed, and maybe matplotlib is considered a subset of scipy.

Now that scipy is supported, I'll start taking a look at python 3.


Funny, not sure how they assemble this table

Take gunicorn for example, marked green. On the website it says:

Gunicorn requires Python 2.x >= 2.6. Python 3.x support is planned.


It says the information is from PyPI, and gunicorn is in the "Python 3" category on PyPI. That might be it.

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.


Why are the packages not sorted by names ? Tornado not there ? Wtf with the background ?


I assume they're sorted by the number of downloads from the Python packaging index (PyPI).

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>


The big one not on this list (because not in PiP) is SCons.


Does that matter though? SCons is a standalone program and you can easily have parallel versions of Python installed.


I'd never heard of this module until now. Have you successfully replaced Make with SCons in your projects?


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.


The startup I work for uses scons for all of our projects other than Java/Python. So C++/C mainly.

Without it we'd most likely still be pulling our hair out trying to deal with make/cmake/qmake/what have you...


waf (a fork of scons) works on Python 3 already.


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.


This could be the year of Python 3.0 on the desk^H^H^H^Hserv^H^H^H^H...looks like we need to keep waiting. Maybe I can one day use Django on 3.0.

:(

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.


Django 1.5 is in python 3. Soon it shall be so.

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 is in python 3

Django 1.5 has experimental Python3 compatibility.


Well yes, they said it isn't recommended in production. But, it's definitely a step forward.


Fabric depends on Paramiko, which is still red anyway.


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.


That day could be today, for Django.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: