Google Groups Home
Help | Sign in
Message from discussion Django 1.0 features -- the definitive list
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
Graham Dumpleton  
View profile
 More options Nov 30 2007, 4:37 am
From: Graham Dumpleton <Graham.Dumple...@gmail.com>
Date: Fri, 30 Nov 2007 01:37:43 -0800 (PST)
Local: Fri, Nov 30 2007 4:37 am
Subject: Re: Django 1.0 features -- the definitive list

Adrian Holovaty wrote:
> (I've been saving this e-mail since the last sprint. Given that we're
> sprinting again this weekend, I figured it was about time to get this
> conversation started.)

> Let's get a definitive list of features we want in Django 1.0, and
> let's release it.

> I'll start with a proposed list, which no doubt has omissions. But
> first, here's a proposal for how to handle this:

>     1. We decide on the list of features/changes.

>     1.5. Once the list is final, we do NOT add to it except in case of
> an Act of God.

>     2. We set a deadline.

>     3. We work -- *primarily* on the list of features/changes, but
> allowing some time for squeezing in any other small fixes that we have
> time for.

>     4. Any feature that's not implemented by the deadline does NOT
> make it into version 1.0. But fear not, because version 1.0 is not the
> end of Django -- it's only the beginning!

>     5. Release, rejoice.

> The first order of business is deciding the features/changes. I'll
> kick it off with the list I've been keeping.

> This is just my own list, of course, and I'm sure other
> committers/contributors have other stuff. Please contribute! Just one
> important thing to note: This list is for Big Stuff only. Do not
> suggest features that would be able to be added/changed *after* the
> 1.0 release in a backwards-compatible way. The goal here is to have a
> simple, concrete list of major things that need to be done to the
> framework -- not a list of 4,000 tiny things.

> Without further ado, here's my list:

> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an instance
> * #5361 -- File storage refactoring
> * #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff

> What am I forgetting?

There is probably no ticket for it, but allowing a WSGI environment
variable be used in place of DJANGO_SETTINGS_MODULE environment
variable. The intent in doing this is to get away from dependence on
what is effectively a global variable. This would perhaps allow, or at
least be a step on the way to being able to effectively host multiple
Django site instances within the one Python interpreter. This would be
better than using distinct sub interpreters in mod_python or mod_wsgi
as only have to load common modules into memory once, thus cutting
down on memory bloat when hosting a lot of sites.

I think a lot of people who are hosting a lot of related sites on the
one system would appreciate this one.

Graham


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2008 Google