I'd like to officially drop Python 2.3 support in Django 1.1. Discuss.
Oh god please, YES! Gimme my decorator syntax sugar, oh yeah.
... and generator expressions, too!
+1. This needs to happen. Python 2.3 is getting pretty old and I would
imagine that most people have at least 2.4 available to them or they
can hang out in 1.0 land until they are able to upgrade. Remember
PyCon 2008? :)
-- Ned Batchelder, http://nedbatchelder.com
+1, every single reason that has been stated convinces me of dropping
support for 2.3.
+0.5 (not withstanding any panic'ed folks saying "I need 2.3!",
consider it a +1)
I think Debian Stable has moved to 2.4. All the servers that I
touch currently with 2.3 on them now also have 2.4 on them.
Yay, decorators, generators, and built-in sets!
Antoni Aloy López
I'm going to be the stick in the mud and say -0.
I don't have any particular love of or need for Python 2.3, but it has
taken us a lot of effort to get and maintain Python 2.3 compatibility.
I know maintaining this support is a pain, but in the grand scheme of
things it doesn't bite us that often.
I know the GIS stuff is bound to 2.4+, but other than this, is there
any particularly compelling reason to drop 2.3 support other than the
annoyance factor for 1.1? I'm just not convinced that the first minor
release after a major 1.0 release is the right time to do it.
Mostly it's the annoyance factor, but I think it goes a bit further
than "annoyance" -- there's a *lot* of places where we have to work
around 2.3 problems. It'd simplify quite a few nasty spots to be able
to factor 2.3 out.
The reason we have to do it at *some* time is it's really the first
step towards Python 3.0 compatibility. We really won't be able to go
2.3+ ---> 3.0 all the way in one fell swoop, so we'll need to work up
to it. In my experiments it seemed that going 2.5 -> 3.0 is pretty
painless (the work Martin van Lowis did can be adapted easily to
support both 2.5, 2.6, and 3.0, but not earlier). So we need to start
down the road of deprecating older versions in preparation for an
eventual move to 3.0.
Of course, we're talking a timeline measured in years here, but the
road start now.
I'm not really feeling strongly one way or the other, although all the
people slobbering over "decorators" is not a reason to do it. Most of
the compatibility stuff is minor and doesn't interfere when you're not
using 2.3. It's not that hard to be 2.3-compatible when writing code
("oh, noes! I have to remember to do a three line thing to import sets
manually when writing a patch for django core that doesn't already use
The only reason I'd lean slightly towards dropping 2.3 is it will make
it more feasible to maintain a python 3.0 version in parallel. The
current unicode bug that requires us to wrap a lot of objects in
unicode() calls is only for 2.3 and really makes the 2to3 passage
painful, for example.
However, even saying Django 1.1 is the last 2.3-compatible version and
we drop it afterwards gives us a reasonable 3.0 support timeline, since
our timeframe doesn't really encourage any official 3.0 support for 1.1.
End of the day: I'm happy whichever way we go.
Maybe put up a poll, prominently, on the djangoproject.com homepage?
Maybe make a timeline? Drop 2.3-support by date x, drop 2.4-support by
date y, drop 2.5-support by date z, then stay with 2.6 until all the
world is 3.x?
Python 2.6 for django 2.x maybe?
This sounds like a reasonable approach to me. It gives plenty of
warning that the change is going to happen, and allows us to provide a
speculative answer to the "when will you support Python 3.0" question.
However, as with Malcolm - if the BDFL's want 2.3 gone for v1.1, I
won't kick up a fuss.
> However, even saying Django 1.1 is the last 2.3-compatible version
> and we drop it afterwards gives us a reasonable 3.0 support
> timeline, since our timeframe doesn't really encourage any official
> 3.0 support for 1.1.
Agreed, and I think it is good practice to announce end of support for
something in the *previous* release announcement i.e. in the Django
1.1 release announcement we say "This is the last release that will
support Python 2.3". This gives people sufficient time to make the
switch by the time the next version of Django comes out, and means
that anyone following new features in Django with interest will not
have a nasty surprise. We could perhaps put a deprecation warning
for Python 2.3 itself starting from 1.1.
"Mistakes: It could be that the purpose of your life is only to serve
as a warning to others." (despair.com)
Luke Plant || http://lukeplant.me.uk/
Actually, dropping 2.3 support was openly discussed for 1.0 at PyCon
2008. In a room with at least 60 developers, I was the only one that
raised my hand when Jacob asked about people using Python 2.3 (I had
RHEL4 boxes in production). Also at PyCon, the core developers later
decided to keep 2.3 support for 1.0 and drop it shortly afterwards
(Jacob, looks like we still need to post those meeting minutes:
Digging through my notes here, it seems that a big reason for keeping
Python 2.3 support for 1.0 was for the benefit of the
Jython/IronPython/PyPy folks. I'm not sure how these areas have come
along since then. jython.org seems down at the moment, but from the
IronPython page, I gather they are at CPython 2.4 and 2.5
compatibility levels  with their 1.x and 2.x releases,
respectively. If Python 2.3 support still helps these folks then then
I would be in favor of keeping 2.3 support around for 1.1.
Otherwise, I'm all for dropping 2.3 support, as maintaining 2.3
support is not fun at all. Just dig through changesets and note all
of the 2.3 bugs that were introduced and fixed over the last major
development cycle, for example. Python 2.3 unicode bugs have been the
most annoying, but there have been a few rsplit, list generator, and
other syntax bugs as well. Testing is made easier, too, since it
means one less version of Python to test against.
As for the roadmap, I think that is the point of this discussion. We
are finalizing the features for 1.1, and if Python 2.3 support is to
be dropped, then this fact will indeed need to be noted on the roadmap
along with the other planned features. Those needing to stay on
Python 2.3 could just keep to 1.0.x, not unreasonable if you ask me.
Also, 1.1 is still four months away and 1.0.x will be receiving bug
fixes until then, so Python 2.3 users wouldn't be completely left in
This chestnut is something that people bring up now and again and it's
always incorrect. Just because python.org is not supporting Python 2.3
does not mean that everybody using it is using an unsupported version of
Python. That would only be true if the only place you received security
patches and support from was python.org. In fact, most people using
Python 2.3 in production environments these days will have never
received support from python.org. They will be getting support through
their vendor. Red Hat Enterprise Linux is one obvious example that has a
very long lifetime and guaranteed support throughout that lifetime
(including security patches). Other vendors provide similar support.
It's not really a strong argument either way for the most part, since if
you want to run the latest version of Django, you're not exactly getting
that through your vendor, so installing a local copy of a more recent
Python is also not entirely tragic. But it's not correct to make these
claims that people should never be running 2.3, since it's patently
+1 -- because reusable apps developers could all close those
py2.3-related bugs as wontfix. One less cost to share share code with
Eduardo de Oliveira Padoan
"Distrust those in whom the desire to punish is strong." -- Goethe,
1. Until recently, we didn't have a stable Django release series on
which to begin considering the process of dropping support in
anticipation of Python 3.0.
2. Python 3.0 isn't available yet.
But now that we have 1.0 (and 1.0.1, and 1.0.2) out the door and 1.1
in planning, and now that Python 3.0 is imminent, I'm going to dump
out my thoughts on the matter in a semi-organized fashion. If you want
to skip the boring bits and just read the conclusion, scroll down.
The first thing which comes to my mind is a simple question: who's
still stuck with Python 2.3? Anyone whose only option is 2.3 will,
obviously, no longer be able to use Django if we drop 2.3 support and
I'd hate to strand people who want to use Django but don't have the
ability to deploy on a more recent Python. This is also, IMHO, the
strongest argument in favor of maintaining 2.3 support for as long as
Availability of Python 2.4-compatible platforms
So to get things rolling, I spent some time researching the (C)Python
version supported by various alternative Python implementations and
operating systems. What I ended up with is, of course, an incomplete
list, but I think I've at least hit all the major platforms we need to
First up, the alternative Python implementations:
* Jython: Jython 2.2.x is roughly equivalent to CPython 2.2, and
Django has never run on CPython 2.2 so that's a wash. The upcoming
Jython 2.5 will be roughly equivalent to CPython 2.5, and so
dropping CPython 2.3 support will not affect users of Jython.
* IronPython: IronPython 1.0.x and 1.1.x seem to be (someone correct
me if I'm wrong) roughly equivalent to CPython 2.4, and the
forthcoming IronPython 2.x will be roughly equivalent to CPython
2.5. So dropping CPython 2.3 support will not affect users of
Then there are the operating systems:
* Windows: Windows doesn't ship Python, so developers wishing to use
Django on Windows will need to install Python and will, presumably,
grab the latest Python they can get. Dropping 2.3 support, then, is
unlikely to affect Windows users.
* Mac OS X: OS X 10.3 (Panther) and 10.4 (Tiger) shipped Python 2.3;
10.5 (Leopard) shipped Python 2.5. Thus, dropping 2.3 support may
pose a problem for OS X users who have neither upgraded to Leopard
nor installed a more recent Python build (but, of course, a number
of useful/necessary bits to go with Django are difficult or
impossible to build on stock OS X, so I'd imagine most people using
Django on pre-Leopard OS X have installed their own Python,
presumably a more recent version).
* Red Hat Enterprise Linux/CentOS: RHEL 5 / CentOS 5 ship Python
2.4. RHEL 4 / CentOS 4 ship Python 2.3. Earlier versions appear to
have shipped Python 2.2 or older, making this moot for versions
prior to RHEL / CentOS 4, but there's more to consider here than
will fit in a bullet point (see below).
* Fedora Linux: Python 2.4 appears to be available for releases back
to Fedora 6. The current release is Fedora 10.
* Debian GNU/Linux: Current Debian stable (Etch) ships Python 2.4.
* Ubuntu Linux: Ubuntu Linux 6.06 LTS (Dapper Drake), the oldest
currently-supported release, shipped Python 2.4.
* SUSE Linux Enterprise: SUSE LE 10 ships Python 2.4. SUSE LE 9
shipped Python 2.3.
* openSUSE: openSUSE 10.2 shipped Python 2.5.
* Solaris: I'm unable to find information detailing which Python
version ships with various releases of Solaris and OpenSolaris. If
anyone has that information, please post it in a reply.
* NetBSD: Python 2.4 appears to have first become available in the
ports tree for NetBSD 2.1. The current release of NetBSD is 4.0.1.
* FreeBSD: Python 2.4 appears to have first become available in the
ports tree for FreeBSD 4.11. The current release of FreeBSD is 7.0.
* OpenBSD: Python 2.4 is available for the current release of OpenBSD
(4.4). I'm unable to find historical information detailing when
Python 2.4 first became available in the OpenBSD ports tree.
What this all means, part 1
For the overwhelming majority of platforms in the above lists,
dropping 2.3 compatibility should pose no problem, because 2.4 or
later (or 2.4-compatible or later) are available. This is the good
The bad news is contained simply in the list of platforms which won't
fare so well if we drop Python 2.3 support:
* Red Hat Enterprise Linux 4 / CentOS 4
* SUSE Linux Enterprise 9
I don't know offhand how widely Django is deployed on SUSE LE 9, but I
know from experience that a *lot* of corporate Django deployment takes
place on RHEL 4 / CentOS 4. That's a problem in and of itself, but it
gets worse when you take into account the fact that many of those
deployments cannot, in effect, upgrade to a more recent Python version
without voiding their support contracts (of course, in theory they can
install and maintain a more recent Python in parallel, but in practice
this is more trouble than it's worth).
Oh, and one more bit of doom and gloom: RHEL / CentOS supports
releases for seven years, meaning RHEL 4 / CentOS 4 will not reach
end-of-life until 2012.
Thus, the only way users of these platforms will be able to use a
Django release which drops 2.3 compatibility is by upgrading to RHEL 5
/ CentOS 5 or later and, of course, corporate deployments are
notoriously rather conservative about such upgrades.
Also, note that the argument, raised multiple times already, about
upstream support from Python itself for 2.3 is moot; distributions
like RHEL which ship Python 2.3 are committed to supporting it until
their own EOL dates regardless of what upstream Python does.
A pop-culture segue
Many of you have perhaps seen the 1990 film adaptation of Tom Clancy's
novel "The Hunt for Red October", which concerns a Soviet
nuclear-missile submarine whose captain and officers are attempting to
defect. The protagonist, American CIA analyst Jack Ryan, is in one
scene mulling how to remove the crew from the submarine without making
them aware of their officers' intentions:
Wait a minute. We don't have to figure out how to get the crew off
the sub. He's already done that, he would have had to. All we
gotta do is figure out what he's gonna do. So how's he gonna get
the crew off the sub? They have to want to get off. How do you get
a crew to want to get off a submarine? How do you get a crew to
want to get off a nuclear sub...
At this point, our intrepid hero has an epiphany and is able to
formulate a plan for action.
What this all means, part 2
In short: we don't have to figure out how to get "enterprise"
deployments to upgrade. All we have to figure out is how those
deployments are going to get into a situation where they *want* to
upgrade. And the answer is, simply, Python 3.0.
Over the next year or two, an ever-increasing amount of Python
software will be going through the same process we're currently
contemplating: dropping support for Python versions in anticipation of
eventually running either only on Python 3.0, or on Python 3.0 and
Python 2.6. So even though RHEL 4 (for example) won't EOL until 2012,
the point at which the scarcity of available and useful software
running on Python 2.3 will become a suitable upgrade incentive will
likely occur much sooner.
In other words, a time will come, possibly fairly soon, when these
folks will want to "get off the boat" of their own accord. And so we
probably don't need to worry too much about it right now.
A schedule for dropping Python 2.x support
The only thing left, then, is to decide on a timeline for dropping our
support for various 2.x Python releases. I don't entirely agree with
the proposal to drop 2.3 immediately with Django 1.1, because I'd
prefer to give users and distributors of Django a bit more warning;
dropping support for a Python version is the sort of thing which
really needs to involve more than (at this point) four months' advance
notice, so that people who are affected will have enough time to start
planning upgrades and migrations.
Additionally, for platforms which support multiple parallel Python
versions on the same system (e.g., Debian's python-support system),
giving a bit more lead time is important so that their packaging
processes can test and update dependencies for Django and related
So I'd like to propose an alternative: we provide one full release
cycle's advance warning before we drop support for an older Python
This would mean the earliest we could drop Python 2.3 would be Django
1.2, and I'd envision the progression going something like this
(assuming two Django releases per year, a not-unreasonable supposition
at this point):
* First half of 2009: Django 1.1 is released, with a notification that
it will be the final release supporting Python 2.3.
* Second half of 2009: Django 1.2 is released, drops Python 2.3
support and is the final release supporting Python 2.4.
* First half of 2010: Django 1.3 is released, drops Python 2.4 support
and is the final release supporting Python 2.5.
* Second half of 2010: Django 1.4 is released and drops Python 2.5
This gets us to a situation where, about a year after the release of
Python 3.0, Django will be ready to make the transition -- the only
2.x Python we'll be supporting is Python 2.6, and 2to3 plus manual
effort and available supporting libraries should make it possible to
also run Django on Python 3.0 either at that point or not long after.
From there, 2.6 support can be dropped whenever convenient, and Django
can move to running only on Python 3.x at whatever time is judged
If we end up doing a few longer (e.g., 9-month instead of 6-month)
release cycles, obviously that point will be pushed back further into
2010, but I think that's perfectly acceptable.
This also has the advantage of giving existing and prospective Django
deployments a longer-term timeline to refer to; there are plenty of
places where an operating-system upgrade needs more than six months'
advance planning, and being able to know well ahead of time when their
current platform will lose official Django support will likely help
those places considerably.
Implications for Django development
The biggest issue I can see for this, in terms of Django's own
development, is how to maintain the parallel bugfixes/feature
development system we've committed to. If, for example, we release
Django 1.2 with the intention that it will be the final 2.4-compatible
release, we'll need to ensure that any backported fixes into 1.2.x
releases still maintain that compatibility.
This probably won't be too difficult, since it doesn't seem likely
that we'll be doing major rewrites of the Django codebase to take
advantage of more recent Python features. Rather, incompatibilities
with unsupported Python versions will simply enter the codebase when
they make sense as improvements to Django. So this isn't likely to be
a big issue.
Implications for Django distribution and community support
Finally, none of this should be taken to mean that it must become
impossible for Django to continue running on older Python releases;
rather, the only change will be that the core Django development team
will no longer support that use case and will no longer take care to
preserve compatibility with older Python releases.
Since, as I've mentioned above, there are already Linux distributions
committed to maintaining Python 2.3 support for several years into the
future, I wouldn't be surprised if motivated distributors and members
of the community continue to organize and provide their own support
for Django on older Python releases, independently of what we
officially do. A similar situation already exists in terms of older
Django releases which no longer receive official support, but which
several people, myself included, have continued to patch on our own as
part of our duties to our employers or our employers' clients.
So if there are (and I suspect there will be) enough people interested
in maintaining unofficial Django source trees or packages which
continue compatibility for particular Python versions after we've
officially dropped support for those versions, I don't think we should
(or can -- this is open-source software, after all) get in their way.
The only problem I can foresee there is how to handle the need to call
those unofficial, unsupported codebases "Django". I'd really like to
avoid getting into the nasty, community-goodwill-killing situations
trademark issues can cause (see Mozilla for a shining example of how
*not* to protect an open-source trademark), so maybe the DSF could put
some its funds to use by chatting with an attorney about the best way
to deal with that.
So, as promised, that ended up being pretty long. But here are the
* We shouldn't worry too much about platforms which still only offer
Python 2.3, because people on those platforms will end up with their
own incentive to upgrade as various Python projects drop support in
the run up to Python 3.0 migration.
* We shouldn't drop Python 2.3 support in Django 1.1; the earliest we
should do that is Django 1.2, and we should provide a timeline
explaining how we'll proceed from there to dropping other 2.x Python
* Dropping 2.x Python versions as we go probably won't cause any major
headaches, just an occasional need to be careful when backporting a
* Even after Django officially drops support for a particular Python
version, that shouldn't necessarily be the end of the line; people
who want or need to continue maintaining support on their own can
and should be able to.
And... I'm spent.
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
> On Tue, Nov 25, 2008 at 3:08 PM, Jacob Kaplan-Moss
> <jacob.ka...@gmail.com> wrote:
>> Hi folks --
>> I'd like to officially drop Python 2.3 support in Django 1.1.
> +1 -- because reusable apps developers could all close those
> py2.3-related bugs as wontfix.
But who has submitted those bugs? That's the interesting point.
Thanks, James, for your post-doctoral dissertation on the History
and Cumulative Predicted Future of Python Versions and Their
Interrelations With the Django Development Process. :-) (joking
aside, it was an appreciated and well-researched post)
For the most part, I give a +1 to James's plan of action. The
only item I'd tweak is giving hard cut-off correlations between
Django versions and Python version. Just as his Hunt for Red
October example shows, Python shouldn't be *forcing* Django to
bump up the supported version number, but rather making
developers *want* to drop support.
It seems the current catalyst for the "drop 2.3" thread is that
2.3 has baggage associated with it that keeps Django from
evolving as rapidly as developers want. Whether decorator
syntax, built-in sets, generator syntax, performance issues, bugs
related to 2.3'ness, testability, or whichever other aspect that
2.3 lacks, it's putting a drain on developers to be backwards
compatible. And from the dialog on this list, there's a clear
developer *want* to drop 2.3
However, I haven't seen any/much expression of *want* that 2.4 be
dropped any time in the near future (and there are a much larger
number of 2.4 deployments). I wouldn't schedule that "2.4 will
be dropped in Django 1.3" timetable, but rather a similar lead-up
process as 2.3 has experienced -- a JKM post of "dropping 2.4
support. Discuss" when 2.4 starts causing enough problems to be
more trouble than it's worth.
So I'm somewhere between -0 and -1 on the voting scale regarding
forced/long-range Python-version deprecation. But when a version
becomes sufficiently dead weight, slowing down Django's progress
like 2.3 seems to be doing, I'm +0 to +1 on dropping it with one
Django-version worth of notice. Once the decision has been made,
release one last Django version with a "this is the last version
of Django to support Python version X" notice (judicious timing
of the discussion-to-drop shortly after an official Django
release would help).
My 2.8571428571428573e-11 of the $700-billion bailout...