Dropping Python 2.3 compatibility for Django 1.1
Jacob Kaplan-Moss
I'd like to officially drop Python 2.3 support in Django 1.1. Discuss.
Jacob
J. Cliff Dyer
workplace is finally getting off RHEL 4, which had Py 2.3, so I no
longer have an issue with dropping 2.3 support. RHEL 5 is at 2.4. Are
other places are still stuck with RHEL 4?
Even before, the install notes for contrib.gis called for Python 2.4,
which actually helped push us to RHEL 5.
I also think it's a better situation abandoning Py 2.3 people at django
1.0.x rather than at 0.96.x.
+0. I'm okay with it.
Cheers,
Cliff
Ludvig Ericson
> 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.
- Ludvig.
Ivan Sagalaev
... and generator expressions, too!
+1
alex....@gmail.com
before that Djagno-dev, even if 20 people are vocally in favor of
something, is a tiny fraction of all the people using Django, is there
perhaps a better/more objective way of collecting feedback(the
obviously, perhaps only, argument against is that some people don't
have access to it, the only question is that a sizeable portion of
Django users).
alex
Brian Rosner
+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? :)
--
Brian Rosner
http://oebfare.com
Horst Gutmann
Finally real decorators, generators and not to forget sets as built-in type :D
-- Horst
Ned Batchelder
--Ned.
http://nedbatchelder.com
-- Ned Batchelder, http://nedbatchelder.com
Jannis Leidel
+1, every single reason that has been stated convinces me of dropping
support for 2.3.
Cheers,
Jannis
Tim Chase
> Discuss.
+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!
-tim
Justin Bronn
around a three thousand line Decimal implementation.
-Justin
Antoni Aloy
2.4 is still quite conservative :)
The actual Django stable version is good enought to let people
developing in until the decide/can move to a new version
--
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net
zvoase
If people want to use the cutting-edge Django release then they can at
least update Python to 2.4 (which is now 4 years old anyway).
Russell Keith-Magee
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.
Russ %-)
Jacob Kaplan-Moss
<freakb...@gmail.com> wrote:
> 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.
Jacob
Malcolm Tredinnick
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
it." Puh-leeze!)
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.
Regards,
Malcolm
Julien Phalip
wrote:
>
advance. For example: "Python 2.3 support will be dropped in Django
1.3, so be warned and get ready for it."
Hanne Moa
<jacob.ka...@gmail.com> wrote:
> I'd like to officially drop Python 2.3 support in Django 1.1. Discuss.
Yes please.
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?
HM
Ben Godfrey
Having a clear roadmap before you make changes is really helpful. I've
been bitten by changes appearing in code suddenly because I've tuned
out for a few weeks. There is always the option of sticking to an
earlier revision, but that doesn't help for long.
I also agree it's worth getting a feel for the need for 2.3. I'm sure
there's quite a few RHEL <5 boxes out there for example. Ned's
suggestion is a cunning one, but a Q on the user list might be a
useful first move.
Ben
Russell Keith-Magee
<mal...@pointy-stick.com> wrote:
>
> 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.
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.
Russ %-)
mrts
can
rely on.
Django 1.1 should drop Python 2.3 support for the following reasons
not
mentioned or elaborated above:
* Python 2.3 is officially not supported by Python developers since
2.3.5; it
doesn't even receive security patches -- so, effectively, everybody
should
avoid using it (the same is true for 2.4, 2.4.5 is supposedly the
last release
in the series). It doesn't make sense to support something that is
deprecated upstream.
* as opposed to decorators that are just syntactic sugar, generator
expressions provide a way to avoid using list comprehension (and
thus building the full list where it is actually not needed)
throughout.
Considerable memory savings are possible by using the former,
see PEP 289.
* there are many minor things, e.g. rsplit and key in cmp, that make
code
considerably more efficient. For the quite common idiom
"extract the last chunk from string separated by some separator":
>>> from django.contrib.webdesign.lorem_ipsum import words
>>> WORDS = words(10) # for larger strings the gain is more dramatic
>>> timeit.timeit('WORDS.rsplit(" ", 1)[-1]', 'from __main__ import WORDS')
0.84617710113525391
>>> timeit.timeit('WORDS.split(" ")[-1]', 'from __main__ import WORDS')
1.7152390480041504
Also, urandom, getrandbits, and threading.local.
---
I'd like to see someone stand up and declare "I'm *planning* to use
Python 2.3
for my next large scale project that will be based on the upcoming
Django 1.1 because of X and therefore I'd like to see 2.3 supported".
If nobody steps up with the rationale X (apart from "because we can"),
I really don't see why 2.3 should be dragged along and keep hindering
efficiency.
Luke Plant
> 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.
Luke
--
"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/
varikin
wrote:
> 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.
and dropped sometime in the future). Pulling support for something is
large step and was never discussed for 1.1 openly till now. Anyone who
has read the roadmap but not following any more than that could be in
for a nasty surprise.
-John
Gary Wilson Jr.
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:
http://www.djangoproject.com/foundation/records/).
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 [1] 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
the dark.
Gary
[1] http://www.codeplex.com/IronPython/Wiki/View.aspx?title=Differences
David Cramer
Update your damn distros. Generators are important :)
On Nov 26, 10:33 am, "Gary Wilson Jr." <gary.wil...@gmail.com> wrote:
Malcolm Tredinnick
On Wed, 2008-11-26 at 01:42 -0800, mrts wrote:
[...]
> * Python 2.3 is officially not supported by Python developers since
> 2.3.5; it
> doesn't even receive security patches -- so, effectively, everybody
> should
> avoid using it (the same is true for 2.4, 2.4.5 is supposedly the
> last release
> in the series). It doesn't make sense to support something that is
> deprecated upstream.
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
false.
Regards,
Malcolm
Eduardo O. Padoan
<jacob.ka...@gmail.com> wrote:
>
> Hi folks --
>
> I'd like to officially drop Python 2.3 support in Django 1.1. Discuss.
>
+1 -- because reusable apps developers could all close those
py2.3-related bugs as wontfix. One less cost to share share code with
the community!
--
Eduardo de Oliveira Padoan
http://djangopeople.net/edcrypt/
"Distrust those in whom the desire to punish is strong." -- Goethe,
Nietzsche, Dostoevsky
Mike Scott
James Bennett
my thoughts about Python version compatibility for a while, mostly due
to the fact that:
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.
Now.
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
possible.
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
worry about.
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
IronPython.
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
news.
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
software.
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
version.
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
support.
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
appropriate.
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.
Conclusions
===========
So, as promised, that ended up being pretty long. But here are the
salient points:
* 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
versions.
* 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
bugfix.
* 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."
David Larlet
Le 27 nov. 08 à 02:39, Eduardo O. Padoan a écrit :
>
> 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.
>> Discuss.
>>
>> Jacob
>
> +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.
David, +1
Tim Chase
> Apologies for the length of this email,
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...
-tim
Justin Lilly
On Nov 27, 2008, at 8:20 AM, Tim Chase wrote:
>
> 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.
I think a big point to remember here is that, while there isn't a
desire to drop 2.4 right now, it won't stay that way. With 3.0 coming,
I'm sure we're going to want to make the switch before long (6 months?
1 year?) During that time, you don't want to say Python versions 2.4
and 2.5 will no longer be supported by django.
With a goal of 3.0 compatibility like James mentioned, you'll want to
provide a roadmap of upgrades. If I have to upgrade my RHEL 4 to RHEL
5 b/c django drops 2.3 support, and I get 2.4, then in 6 months you
want me to upgrade to get 2.5, then in another 6 months, upgrade to
2.6 / 3.0... you're going to make some sysadmins very unhappy.
Conversely, the ability to upgrade from 2.3 to 2.5 will make the
transition much easier because you know you're set for at least 2
releases (1+ year).
I'm +0 to dropping 2.3 support and +1 to having a deprecation roadmap
that spells out which versions will lose support and when.
-justin
James Bennett
<django...@tim.thechases.com> wrote:
> 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).
Well, the big impetus is, of course, Python 3, where the recommended
upgrade process is to get to where the software runs on Python 2.6
(which supports various 3.0-style things that previous 2.x releases
don't and won't) without warnings, and then use 2to3 to help manage
the final transition. Along the way, of course, we'll most likely need
to drop support for older Python versions and so a timeline of how
we're going to do that is a good thing.
Also, note that the timeline I proposed puts the final 2.6-only
support something like two years in the future, which should be plenty
of time for people to get ready and for the benefits of 2.6/3.0 to
become sufficient incentives that we'd want to be at that point.
mattim...@gmail.com
On Nov 27, 2:13 pm, "James Bennett" <ubernost...@gmail.com> wrote:
> * 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.
Solaris 10 originally shipped with Python 2.3.3 as part of the bundled
Sun Freeware under /usr/sfw, but over a year ago it was updated to
Python 2.4.4 installed under /usr and 2.3 still under /usr/sfw for
backward compatibility. There are both 32 bit and 64 bit binaries
installed for 2.4.
OpenSolaris has Python 2.4.4.
cheers
Matthew
--
http://wadofstuff.blogspot.com