Django 1.3 and Python 2.4
Paul McMillan
talk of dropping a version of Python per Django release. Python 2.4 is
relatively rare these days, but still supported by RHEL.
None of us like coding for it, and I know that several of the core
devs have voiced support in IRC for dropping 2.4.
I'm asking for an official pronouncement about the matter:
Are we dropping support for 2.4 in 1.3?
The reason I'm asking strongly for a decision now, rather than putting
it off till later is that if we can overcome our inertia and make a
public decision, we can all stop coding for 2.4 tomorrow. If we ignore
the matter, or put it off till DC.us, we've spent that much more
wasted time coding around a set of problems we could have avoided.
Trunk currently isn't 2.4 compatible - is this a bug, or an official position?
http://code.djangoproject.com/ticket/14086
For what little it matters, I'm very strongly +1 for dropping 2.4, but
let us do it officially. This may be a case where the majority should
not win the vote; it may best be decided by executive decision.
-Paul
Russell Keith-Magee
> Django 1.2 dropped support for Python 2.3. In the past, there has been
> talk of dropping a version of Python per Django release. Python 2.4 is
> relatively rare these days, but still supported by RHEL.
>
> None of us like coding for it, and I know that several of the core
> devs have voiced support in IRC for dropping 2.4.
>
> I'm asking for an official pronouncement about the matter:
> Are we dropping support for 2.4 in 1.3?
>
> The reason I'm asking strongly for a decision now, rather than putting
> it off till later is that if we can overcome our inertia and make a
> public decision, we can all stop coding for 2.4 tomorrow. If we ignore
> the matter, or put it off till DC.us, we've spent that much more
> wasted time coding around a set of problems we could have avoided.
I don't think this is as big a problem as you perhaps make out.
Supporting 2.3 was a major PITA, because Python 2.4 introduced lots of
language features, including:
* built in sets
* generator expressions
* decorator syntax
* decimal types
* multiline imports
Python 2.5 also introduces new features, but I can only pick three
that I can see an immediate use for:
* conditional expressions
* unified try-except-finally
* with/context managers
1 and 3 are completely new features, with completely new syntax, so
it's relatively easy to avoid accidentally using them. The
try-execpt-finally is change that has bitten us on this occasion, and
I predict this will happen again in the future.
However, in a completely unscientific test, from all the tickets I
worked on over the weekend, not one of them tripped over these new
features; historically, several of them would have tripped over Python
2.3 issues. While there are going to be compatibility problems, I
don't forsee them causing as much drama as supporting Python 2.3
caused.
> Trunk currently isn't 2.4 compatible - is this a bug, or an official position?
> http://code.djangoproject.com/ticket/14086
We haven't made an official decision to deprecate 2.4. Until we do, it's a bug.
> For what little it matters, I'm very strongly +1 for dropping 2.4, but
> let us do it officially. This may be a case where the majority should
> not win the vote; it may best be decided by executive decision.
Agreed that executive fiat will probably be required here.
For the record, I *really* want to drop 2.4, but I just don't think we
can do it quite yet -- at least, not for 1.3.
Claiming a wealth of support in IRC is a self-selecting bias; that's
where I'd expect to see support for the greatest new thing. You're not
going to get complaints about upgrading from people who are happy
using the latest thing.
Providing the opposite sample; as uncontroversial as you may consider
it, I am aware of complaints that were raised over the fact that we
dropped Python 2.3 for 1.2.
Like it or not, RHEL is still a major player in the enterprise market
at the moment. I can't speak for the US, but in Australia at least --
when all those companies got on the Linux bandwagon in the mid 2000's,
they all adopted RHEL, and being large enterprises, they aren't moving
away from that platform in a hurry. I don't particularly want to rush
this segment of Django's market share into the arms of another
framework.
I'd rather defer dropping support for Python 2.4 until Django 1.4;
that way, we can use the 1.3 release notes to draw attention to the
impending deprecation.
On top of that, RHEL5 moves into support mode (production 2) at the
end of Q1 2011, and into long-term support mode (production 3) in Q1
2012. A Django 1.4 release would roughly coincide with the start of
support mode. Also, by that time, RHEL6 will hopefully be out,
hopefully providing a more recent Python release as a baseline, which
will provide a way forward for those with support contracts.
Past that point, I think we will probably be able to get more
aggressive about dropping Python versions, but let's cross that bridge
when we get to it.
Yours,
Russ Magee %-)
Dennis Kaarsemaker
<rus...@keith-magee.com> wrote:
> Like it or not, RHEL is still a major player in the enterprise market
> at the moment. I can't speak for the US, but in Australia at least --
> when all those companies got on the Linux bandwagon in the mid 2000's,
> they all adopted RHEL, and being large enterprises, they aren't moving
> away from that platform in a hurry. I don't particularly want to rush
> this segment of Django's market share into the arms of another
> framework.
>
> I'd rather defer dropping support for Python 2.4 until Django 1.4;
> that way, we can use the 1.3 release notes to draw attention to the
> impending deprecation.
>
> On top of that, RHEL5 moves into support mode (production 2) at the
> end of Q1 2011, and into long-term support mode (production 3) in Q1
> 2012. A Django 1.4 release would roughly coincide with the start of
> support mode. Also, by that time, RHEL6 will hopefully be out,
> hopefully providing a more recent Python release as a baseline, which
> will provide a way forward for those with support contracts.
>
> Past that point, I think we will probably be able to get more
> aggressive about dropping Python versions, but let's cross that bridge
> when we get to it.
As one of those RHEL users in larger environments, I really appreciate
this policy and the fact that you have so far followed it and are
planning to continue doing so. Makes my life a lot easier.
FWIW, RHEL 6 will use python 2.6.
--
Dennis K.
Time is an illusion, lunchtime doubly so.
tiemonster
compiling Python to a different prefix, and then recompiling mod_wsgi
and other modules against this version is really not an option at this
point. If Django 1.3 deprecated support for Python 2.4, then we would
be forced to remain on 1.2 until CentOS/RHEL received an update to
python. I work at a university, and have colleagues at lots of other
universities, and everyone I know that runs Linux is running some
variant of RHEL. This is, in my opinion, unfortunate. However, it's a
cultural shift that's going to take a while. If it were up to me, we
would have been running Ubuntu Server a long time ago...
David Malcolm
> On Wed, Aug 11, 2010 at 2:20 AM, Russell Keith-Magee
> <rus...@keith-magee.com> wrote:
>
> > Like it or not, RHEL is still a major player in the enterprise market
> > at the moment. I can't speak for the US, but in Australia at least --
> > when all those companies got on the Linux bandwagon in the mid 2000's,
> > they all adopted RHEL, and being large enterprises, they aren't moving
> > away from that platform in a hurry. I don't particularly want to rush
> > this segment of Django's market share into the arms of another
> > framework.
> >
> > I'd rather defer dropping support for Python 2.4 until Django 1.4;
> > that way, we can use the 1.3 release notes to draw attention to the
> > impending deprecation.
> >
> > On top of that, RHEL5 moves into support mode (production 2) at the
> > end of Q1 2011, and into long-term support mode (production 3) in Q1
> > 2012. A Django 1.4 release would roughly coincide with the start of
> > support mode. Also, by that time, RHEL6 will hopefully be out,
> > hopefully providing a more recent Python release as a baseline, which
> > will provide a way forward for those with support contracts.
FWIW I've built an unofficial python 2.6 for RHEL5 as part of "EPEL" [1]
to try to ease the transition.
If you're using EPEL5, then:
yum install python26
should get you the interpreter, "python26-devel" for building
extensions, etc. This is parallel-installable with the main python 2.4
runtime.
A (very small) stack of prebuilt rpms against python26 is also available
[2]. Let me know if there are other dependencies you need.
This is a personal side-project of mine, and is not officially supported
by Red Hat.
Hope this is helpful
Dave
[1] http://fedoraproject.org/wiki/EPEL
[2]
https://bugzilla.redhat.com/showdependencytree.cgi?id=573151&hide_resolved=0
(snip)
Russell Keith-Magee
While this is great work, and may be extremely useful to some, it
doesn't fix the problem for the group of people that are most affected
-- the people that need to (for business reasons) maintain their
official RedHat support contracts. For that group, we have to support
the official Python version in RHEL5.
Yours,
Russ Magee %-)