Re: Python 3000 support, any plans?
David Zhou
> I am very interested in Python and Django for a future project but I
> am noticing this is a period of big changes in this community. Python
> 3000 and Django 1.0 will really be a major change.
They will be big changes, but don't really align in terms of timeline.
> I am not afraid of using Alpha versions, and I want to use latest
> technologies and my mind rejects any forced changes in the code due to
> new releases. If I do something I don't want to touch it again.
> So I want to start straight with Python 3000.
Even if you coded in Python 3000, it's not like Django doesn't
sometimes introduce backwards incompatible changes. Plus, I highly
doubt any serious effort will be made to make sure Django works on
Python 3000 until after Django 1.0 and (likely) until after Python
3000 exits alpha state.
> Would this be compatible with Djanga? If not when do you expect it to
> be compatible?
> I prefer waiting than recoding, so I wanted an idea on timelines...
> any thoughts?
I'd posit with fair confidence that Django 1.0 will come long, long
before Python 3000 reaches a non-alpha state.
If you want to use Django for something, I'd start now -- or with
1.0. Waiting for Python 3000 is a bit silly.
---
David Zhou
da...@nodnod.net
Quentin Gallet-Gilles
Django'd better hurry, because the first beta release of Python 3000 is due next month ! And the final release is scheduled for September.
However, that's just a start. Porting the libraries (batteries excluded, of course) is the next big step and it is expected that we will have to wait for 3.1 or 3.2 before the major libraries and frameworks are all ported.
Anyway, I agree it's silly to wait for Python 3000. The 2.x release is not that different and everything is done to make adjusting to Python 3000 as seamless as possible.
Russell Keith-Magee
>
> Hello,
> I am new to Python and Django, I am a ASP.NET C# programmer actually
> tired of following Microsoft's unnatural and crazy page model that
> tries to hide the page from you as much as possible.. seriously how
> did they came up with that?!
>
> I am very interested in Python and Django for a future project but I
> am noticing this is a period of big changes in this community. Python
> 3000 and Django 1.0 will really be a major change.
> technologies and my mind rejects any forced changes in the code due to
> new releases. If I do something I don't want to touch it again.
> So I want to start straight with Python 3000.
>
> be compatible?
> I prefer waiting than recoding, so I wanted an idea on timelines...
> any thoughts?
This came up a little while ago (around the time of PyCon 2008), so if
you search the archives, you can find a lot more discussion on the
topic.
However, the short version:
* There are currently no formal plans to support Python 3000. Efforts
are currently focussed on Django 1.0.
* There isn't a huge need to be on the cutting edge here - we still
maintain Python 2.3 support because it is used by a few deployment
environments that are in common usage. It will be some time before
Python3000 is in common usage everywhere.
* Exploratory work has been done on porting Django to Python 3000 -
initial reports are that there isn't a huge amount of work to be done
on our code base.
* The bigger problem you will encounter isn't Django - it's the chain
of support libraries. At the very least, you will need Python3000
versions of mod_python and a database backend. To the best of my
knowledge, these tools aren't available in Python3000 versions - until
they are, there isn't much point having a Python3000 version of
Django.
* If you follow the official Python guidelines for handling the
2->3000 transition, you shouldn't need to do much recoding of your own
code.
Yours,
Russ Magee %-)
Jeff Anderson
> I have looked on the web and I couldn't find any release date for v.
> 1.0. But I saw they postponed many times before deleting any date from
> their FAQ.
> But I believe u, I'll wait for 1.0 (not for Python 3000) and then I'll
> start, I have enough to do in the mean time :).
>
The development version of django is quite stable, and is much closer to
1.0 than 0.96 is.
You could easily start now with the development version, and learn
enough to get a good feel for django. You won't have to unlearn all that
much to make the transition to 1.0. There will be backwards-incompatible
changes, but they are rigorously documented.
If you have enough to do in the mean time, it wouldn't hurt to at least
go through the django tutorial. [0] It shows how to do most of the
basics-- and is rather fun to do the first time you go through it. :)
Have fun!
Jeff Anderson
Graham Dumpleton
> * The bigger problem you will encounter isn't Django - it's the chain
> of support libraries. At the very least, you will need Python3000
> versions of mod_python and a database backend. To the best of my
> knowledge, these tools aren't available in Python3000 versions - until
> they are, there isn't much point having a Python3000 version of
> Django.
trunk already supports Python 3.0. Thus there already is a Python 3.0
capable solution for Apache hosting.
Personally I can't see mod_python getting ported to Python 3.0 as the
effort would just be too much and anything using the mod_python
specific APIs directly, rather than through a constrained interface
such as WSGI, would also require a lot of rework because it is such a
broad API.
In other words, although Django may use only a subset of mod_python
API, the work in porting all the parts of mod_python it doesn't use
and the impact those changes will have on mod_python specific
frameworks, would most likely deter anyone doing it. Add on top of
this the large list of outstanding issues and problems with
mod_python, which really would want to be addressed at the same time,
and you would have quite a big project that isn't going to get done
very quickly, if at all.
The Django folks would be better off focusing on making Django a well
behaved WSGI citizen, moving away from use of global settings and
instead use a model which would allow multiple Django instances to
operate within the same process, based on per request WSGI
configuration parameters, and thus cut down on memory usage through
sharing of common code modules. They should also address problems with
WSGI SCRIPT_NAME configuration being ignored and look any
multithreading issues to give more certainty that Django will work on
the range of WSGI hosting solutions available.
Graham