I think the problem is that our definitions of "as soon as possible" diverge. To wit:
* Database drivers (psycopg2, MySQLdb, etc.) weren't updated for Python 3 until... last year some time, I think? Django supporting Python 3 is somewhat academic if you can't use a database with it, don't you think?
* The WSGI spec wasn't updated for Python 3 until summer 2011 (July, IIRC). Again, Django supporting Python 3 is pretty academic if you can't run it under a web server, right?
* The previous suggested approach for dual Python 2 and 3 support (using 2to3) proved to be untenable for Django [1], and it wasn't until this last year (or so) that a better approach (single shared source) emerged.
So to my mind, "as soon as possible" was something like July 2011. We had unmet dependencies before then; moving would have been... well, not impossible, but incredibly painful and nearly useless.
I will, however, take full responsibility for not getting Python 3 support shipped between then and how. Our current release workflow [2] got in the way, and about 7-8 months because of it. That's my fault, and if you want to rake me over the coals for those months go right ahead: I deserve it.
[1] Details omitted to be concise, though I'm happy to share them if anyone's interested.
[2] Which we're changing, mostly because of this silly workflow-induced delay.
I'm fully aware that the whole migration disaster isn't primarily Django's fault. But Django is in a position to put pressure on others by simply creating facts and that hasn't happened.
I'm sure you could have found a way to talk to web servers without waiting years for the WSGI spec to be finalized. And if Django had supported Python 3 using py-postgresql, which was released in 2009 (I know Python 3 only), others would have worked a little faster to make their database systems available on Python 3 as well. Upgrading psycopg can't be such an incredibly difficult task either.
The reality is, everyone has basically been waiting for everyone else to make a move and it has resulted in deadlock.
> But Django is in a position to put pressure on others by simply creating facts and that hasn't happened.
How exactly does one create a fact? That would be a neat trick.
> I'm sure you could have found a way to talk to web servers without waiting years for the WSGI spec to be finalized.
Indeed, we could have, and it would have benefited Django at the expense of diversity in the Python web world. It probably would have helped our "market share". But that's not how we roll. I'd rather work on something that the whole community can benefit from, and that means standards and specifications.
> And if Django had supported Python 3 using py-postgresql, which was released in 2009 [...]
That's true - I'd forgotten about that library.
> [...] others would have worked a little faster to make their database systems available on Python 3 as well.
That... I'm not so sure about. Volunteer community, limited by free time, etc. I'm fairly sure most people have worked on this stuff just about as fast as they can.
You do realize, of course, that the criticism here applies to you as well. If you feel this strongly you could have added a py-postgresql backend in 2009, you could have come up with a way to run Django under Apache and Python 3, etc. I'm happy to take a lot of the blame for Django's slow movement, but you're also responsible for not channelling your frustration into action.
> The reality is, everyone has basically been waiting for everyone else to make a move and it has resulted in deadlock.
I don't see a deadlock. I see steady movement -- slow, too slow, but movement nonetheless -- towards Python 3. First Python 3.0 came out, and it was horrifically slow, taking away any impetus to use it. So people fixed that. Then, developers ported the low-level libraries (database drivers, network protocol implementations, etc). Then we started moving to higher level libraries and tooling (numpy, wsgi, ...). Now the highest-level libraries (web frameworks, scipy, matplotlib, ...) are porting. Next, and finally, you'll get to port your apps. It's a classic dependency upgrade chain. You can't upgrade layer N until layer N-1 is done.
I share your frustration about the slowness, but that's frankly a characteristic of the Python community. We're relatively conservative, tending to prioritize stability and backwards compatibility over rapid movement. Everyone pretty much expected this process to take a while, and turns out they're right.
How exactly does one create a fact? That would be a neat trick.
As I said, by implementing something instead of waiting for the spec. I totally disagree that it would have helped Django at the expense of everyone else, unless you patented it. Any implementation, even lots of fragmented ones, would have been better than years of stalemate. I guess we'll just have to agree to disagree on that one.
You do realize, of course, that the criticism here applies to you as well
Yes, absolutely, that's a very fair point. I just didn't expect things to move _that_ slowly. With the benefit of hindsight I want to punch myself in the face for not doing it myself.
There isn't any "migration disaster". There was a five (5) year plan laid out by Guido. We are not even into year three (3) yet (or maybe just into it). If anything it is a "patience disaster".
* Database drivers (psycopg2, MySQLdb, etc.) weren't updated for Python 3 until... last year some time, I think? Django supporting Python 3 is somewhat academic if you can't use a database with it, don't you think?
* The WSGI spec wasn't updated for Python 3 until summer 2011 (July, IIRC). Again, Django supporting Python 3 is pretty academic if you can't run it under a web server, right?
* The previous suggested approach for dual Python 2 and 3 support (using 2to3) proved to be untenable for Django [1], and it wasn't until this last year (or so) that a better approach (single shared source) emerged.
So to my mind, "as soon as possible" was something like July 2011. We had unmet dependencies before then; moving would have been... well, not impossible, but incredibly painful and nearly useless.
I will, however, take full responsibility for not getting Python 3 support shipped between then and how. Our current release workflow [2] got in the way, and about 7-8 months because of it. That's my fault, and if you want to rake me over the coals for those months go right ahead: I deserve it.
[1] Details omitted to be concise, though I'm happy to share them if anyone's interested.
[2] Which we're changing, mostly because of this silly workflow-induced delay.