Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




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

Search: