On Nov 26, 3:20 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
> On Nov 26, 11:43 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
>
>
> > On Wed, Nov 26, 2008 at 2:08 AM, Jacob Kaplan-Moss
>
> > <[EMAIL PROTECTED]> wrote:
>
> > > Hi folks --
>
> > > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss.
>
> > 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 %-)
>
> Maybe the best approach would be to warn people one or two releases in
> advance. For example: "Python 2.3 support will be dropped in Django
> 1.3, so be warned and get ready for it."

Django 1.0.X is a solid base that everybody who still uses Python 2.3
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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to