The first Django site to run on Python 3 | Hacker News Reader

The first Django site to run on Python 3

myks.org

283 pointsmYk53 comments

Since the showcase is low on information, here's a summary of the current status:

- the porting strategy is explained here: https://docs.djangoproject.com/en/dev/topics/python3/

- the porting work happens in the master branch; commits related to the Python 3 port are usually prefixed by [py3]: https://github.com/django/django/commits/master

- the test suite doesn't pass yet, but the hardest part is done: http://ci.djangoproject.com/job/Django%20Python3/

- most of the work happened over the last three weeks, and 5 or 6 core developers are contributing significantly

Not only a major boost for Python 3 adoption but also a reference for how Unicode handling [1] can be successfully ported from Python 2.x libraries.

They seem to be on schedule as well, which is brilliant [2].

[1]: http://wiki.python.org/moin/PortingDjangoTo3k [2]: https://www.djangoproject.com/weblog/2012/mar/13/py3k/

yeah we already had in Pyramid 1.3 for ages ;-)

I can never be surprised enough how people are excited about django features that others take for granted.

Do you think they are excited because they are amazed a framework could do such things or maybe because they are happy that the framework they use can now do such things?

Does anyone get excited at the mere thought that some framework, somewhere has a particular feature? If you aren't using Pyramid then what good does it do you?

How well does Pyramid work with Python 3 (production ready)? And what are the pros and cons of Pyramid vs. Flask or some other lighter weight way to build web apps with Python 3?

As far as I can tell, many people use it in production just fine. As for Pyramid vs. Flask, well pyramid gives you more, but you can use it flask-like if you want.

Maybe because they care about Django, not Pyramid?

So glad to see python 3 being adopted more and more by major web frameworks. This might be the wrong place to ask, but have there been any updates on python 3's wsgi or flask support? I've been out of the loop.

PEP 3333.

Armin Ronacher has long been grumpy about Python 3 so don't count on a Flask port any time soon

> Armin Ronacher has long been grumpy about Python 3 so don't count on a Flask port any time soon

There are different reasons for why I am grumpy though. The things that stop me from porting stuff to Python 3 from the side of Python are largely resolved. In that regard I am just a lazy person and nobody cares about Python 3 YET. As far as the general development of the language goes there is still a lot missing in Python 3 that worked in Python 2 so I am not excited yet.

Port will happen though, just have to decide when I will break the API to make it possible. As it stands right now a port won't be possible without breaking Werkzeug's API because it's just one level too low.

>In that regard I am just a lazy person and nobody cares about Python 3 YET.

You'd be surprised.

Ok, this is mostly what I was curious about. Shame because I love flask, yet I agree with a lot of his python 3 opinions :(

python 3's wsgi support is what is enabling frameworks like pyramid and now django to finally move forward with python 3. that only happened like a couple of years ago.

Heck yeah! My startup uses python heavily, and it's ALL Python3 except for the public-facing website... which is currently Django1.4+Python2.7. As recently as six weeks ago, I tried porting it over, and had to abandon the effort... as soon as this gets stable enough, you can bet we'll make the switch.

We are a django shop and I have been concerned about the transition to python 3 for our projects as well as the community in general. Even though I don't think this the end all for a migration, it is a really promising sign. Nice to see this transition starting to occur in the django world.

Relatedly, what's the correct way to install Python 3 on a Linux server (debian based) so I can try this? while keeping Python 2.x.

The last time I tried doing that I ended up in some weird quagmire with the LD_LIBRARY_PATH being messed up. There must be a standard way to install it?

What's wrong with:

apt-get install python3

It's always worked for me.

Django targets Python >= 3.2, and Debian stable provides 3.1.

FYI the demo uses a manually compiled Python.

In that case, I wouldn't worry about installing for all users. I'd build from source and configure with the --prefix argument. Then I'd start Django using that specific Python.

Or, since Django on Python3 doesn't seem production ready yet, I'd "upgrade" to Debian testing or unstable, and hope that by the time Django became production ready Py3.2 was in Debian stable.

If you're currently on stable but are comfortable running a mixed system, you can install python3 from testing to get 3.2.

Check out pythonbrew [1] - it makes installing different Pythons pretty simple. Perhaps not the best solution for a server, though.

[1] https://github.com/utahta/pythonbrew/

EDIT: pythonz is pretty good too (http://saghul.github.com/pythonz/)

Debian and Ubuntu have their own way of managing Python libraries and paths and I can't say I understand it. The modules are stored all over the place, with 'site-packages' being in one place, another called 'distro-packages' (if memory doesn't fail me) somewhere else, and user installed packages in yet another directory. It's hell.

It is absolute confusion, and when you think you've got it, they change it again. I suppose it makes sense to someone somewhere, who probably thinks they're being helpful by inventing all these complicated schemes.

Look up virtualenv and virtualenvwrapper. It isn't quite analogous, but I think of virtualenv as Python's RVM. Works well enough for me.

See this answer here: http://askubuntu.com/questions/14615/how-do-i-make-the-termi...

Awesome, good to see this move forward. However, what is the django ecosystem support like?

That's the next step - authors of 3rd party apps will need to port their code. We've started putting together some documentation to help authors write single-source code (i.e. code that runs on both 2.6+ and 3.2+). The idea is that they'll use the tools we did, plus the things we learned, to port their apps. https://docs.djangoproject.com/en/dev/topics/python3/ is a start on that documentation, and hopefully we can flesh it out even more for 1.5.

Obviously the Django ecosystem can't start supporting Python 3 until Django itself does.

The porting process (which is still in progress for Django) shouldn't be too difficult for most pluggable applications, as Django strongly encourages using unicode everywhere.

What is the estimated release date of Django 1.5?

Django aims for time based releases every nine months (https://docs.djangoproject.com/en/dev/internals/release-proc...). Since 1.4 was released on 23rd March, that would put 1.5 just before Christmas, appropriately enough. But real life might push it back to January.

Does anyone know how they decided on that porting strategy? Why not move to Python three and run 3to2 for backwards compatibility?

3to2 as I understand it works best for supporting Python 2.6 and 2.7

Django had committed to supporting older versions of Python 2.x that weren't Python 3 friendly (largely because of older installations of RHEL and CentOS).

Here was a discussion asking about dropping 2.4 support during development of Django 1.3: http://python.6.n6.nabble.com/Django-1-3-and-Python-2-4-td50...

Django 1.2 still supported Python 2.3+, Django 1.3 supported Python 2.4+, Django 1.4 supported Python 2.5+.

Django 1.5 (which is the current trunk) finally has Python 2.6.5 as its minimum platform which reduces some of the major compatibility pain points.

The porting strategy was decided by rough consensus in the core team.

We wanted a solution that would be convenient for authors of pluggable apps, so they could use the same strategy as Django itself. This is why we used six rather than an ad-hoc compatibility library.

A big advantage of this approach is that they can test on 2.x and 3.x without needing to run any 'translater'. That means the develop-test cycle goes quicker.

As a mainly php dev on the server-side, I've been interested on expanding to Python / Django for some time but the whole v2 and v3 thing put me a bit on hold.

Glad to see it moving.

I don’t use Python for anything so I don’t really care about Django updates, but I found this cool anyway. It was interesting to look through the code on the page in order to figure out how the page printed out that code. It was also interesting to see just how little code (Python, HTML, and CSS) is needed to make a professional-looking page.

nice to see django take python 3 seriously

Best thing I've seen all day.

(Go ahead and downvote me, this comment has absolutely value, yet despite knowing that I'm so happy I still feel compelled to post it. :)

I'm apathetic, but please let's not start the trend of self-aware "downvote me" or "why the downvotes?" comments on this website. I'm of the opinion that it's needless, manipulative clutter.

Whereas the base comment is fine - some things are delightful and there's nothing wrong with saying so.

As long as there aren't a bunch of "me too" comments, of course.

I agree that the former is clutter, but the latter is good, as long as the commenter is clearly trying to learn from/correct whatever mistake they had made. e.g. "This is being downvoted and I don't understand why. Could someone please explain the problem?" or "Why the downvotes? Is it because ...?"

I guess I prefer the fire-and-forget approach, only going back to edit my own comments for spelling and grammar ("EDIT: ... EDIT 2: ... is sort of grating to me). You make a good point though, and I don't believe that comment-self-awareness is universally an attempt at manipulation.

I'll actually upvote you, because I agree this is great. With the 3.3 release almost through the door, 3.x becomes a simply better Python than 2.x and time is ripe to start switching.

Heck, I don't even use Django. But I'm in the lucky position of having been able to switch to Python 3 already (some of my code still has to keep compatibility with 2.6/2.7, which is reasonably doable, but much of it even gets to care about nothing but 3), and I'm happier now than I was on Python 2 - it's a better language now. I'm frustrated about having to defend that view to people who are frustrated about the transitional pain all the time, so a big milestone toward getting that pain behind us is a cause to celebrate. A Python 3 Django is a big deal both pragmatically for all the great sites using it _and_ psychologically for the Python community.

Well, the authors of frameworks and libraries still on Python 2 and without having concrete upgrade plans will have to either do something soon or others will take their space.

Python 3 is here, now.

> the authors of frameworks and libraries still on Python 2 and without having concrete upgrade plans will have to either do something soon or others will take their space.

Do you know of anything new on PIL (http://www.pythonware.com/products/pil/) ? Or any similar library that might replace it for Python 3?

Pillow (https://github.com/python-imaging/Pillow) is a fork of PIL. If you look at recent commits, you'll see one that claims to make it more Python 3 friendly, but not quite Python 3 compatible because of differences in the C code. So maybe a good opportunity for someone to jump in and fix that.

PythonMagick (http://www.imagemagick.org/download/python/) works in Python3. PIL with Python3 support is coming later, apparently.

There is also Wand (http://dahlia.kr/wand/index.html), which, while still alpha, is a very nice ctypes-based, MagickWand API binding. It is also available in pypi, so is easy to install. Support for Python 3 is near-term goal of the project.

There's what claims to be a Python 3 version of the codebase on Christoph Gohlke's Python packages for Windows page (http://www.lfd.uci.edu/~gohlke/pythonlibs/#pil). I haven't tested it.

Until Numpy and Scipy are on Python 3, I'm going to reserve judgement. Python 3 might be here, now, for some things, but there are enough essential libraries out there that aren't, that it's not for most.

Almost all the Python code I've written in the past year has been in Python 3. The libraries you mention have been ported already, as have many other important ones, such as sqlalchemy, lxml, httplib2, and imminently, Django.

Very early on I had plenty of headaches where some library I needed was Python 2.X only, but that's becoming increasingly rare.

Edit: s/eminently/imminently/

I think they already are: http://scipy.github.com/faq.html#do-numpy-and-scipy-support-...

Also, Python 3 will be shipped with the next ubuntu version https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alp...

A trivial search would show that they are on Python 3 (and have been for some time now).

Reply on news.ycombinator.com