Re: Proposal: Replace django.contrib.formtools.wizard

[Anssi Kaariainen]

On Sep 8, 7:47 pm, Stephan Jäkel  wrote:
> Hi Scot,
>
> shacker wrote:
> > Not all forms are completed in a single sitting. We have a form with
> > more than 100 fields, which takes at least two hours for the user to
> > complete. Therefore it's essential that the (authenticated) user be
> > able to save it and return later to edit or complete it. IOTW there is
> > a need for resumable forms. The problem arises when you have required
> > fields - if these aren't filled out yet, form.is_valid() will never
> > pass, so you can't elegantly save it to be resumed later.
>
> This is a real special case. ATM the formwizard isn't able to store invalid
> forms. But if you are at the sprints in Portland, I would be happy to talk
> to you about possible solutions.
>
> Do you have any idea how this could be solved? (maybe you already patched
> the formwizard to support this?)
>
> Cheers,
>
> steph

I might be missing something obvious here, but couldn't the
request.POST be serialized upon temporary save, and then when
continuing work the form will use the saved POST data as its initial
value?

By the way, I am working on creating easy-to-display forms. The idea
is that BoundFields will have .display_value property, which will
return the entered data in human readable format. I think it could be
useful for "preview changes" step. If something like this is needed,
take a look at: http://github.com/akaariai/django/tree/ticket10427.
Basically any form (barring forms with FileFields, which I really
don't know how to handle at the moment) can be shown by using code
like this:

{% for field in form.visible_fields %}
{{ field.label }}: {{field.display_value}}
{% endfor %}

The code should be able to handle MultipleSelectFields and so on.
Unfortunately I haven't had enough time to work on it lately, so there
is still some work to do.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Proposal: adding value and display_value to bound fields.

[Anssi Kaariainen]

Hello all,

This proposal is about adding value and display_value properties to
BoundFields (ticket #10427). The value property gives raw data and
display_value gives the value in user friendly format. For example for
CharField, both value and display_value will be just the raw data. But
for MultipleChoiceField, the value will be something like [1, 3, 14],
that is, not very usable to display to users directly. For
MultipleChoiceField The display_value will be the text representing
the choices.

I can think of at least two usage cases which are not easy to do at
the moment. The first is simply displaying the data of a model to
user. Using this feature you could achieve this by creating a
ModelForm with the instance's data and the following template:

{% for field in form.visible_fields %}
{{ field.label }}: {{field.display_value}}
{% endfor  %}

The other usage case is a workflow which contains first a view page
for the form, with an edit link (Or edit -> preview -> save).  This
would be achieved using the display_value in the preview stage.

As far as I know both of those usage cases are cubersome to do at the
moment, especially for ForeignKey and ManyToMany fields.

The current patch for #10427 implements value and display_value
properties for BoundField. The property values gives raw data using
the following rules:

1. If the form has data for this field, use it;
2. if the form has initial data for this field, use it;
3. if the field has initial data, use it; and lastly
4. use the empty string.

The display_value returns value, except for ChoiceField, which returns
the text of the choice.

The display_value property is clearly not sufficient, as it doesn't
handle MultipleChoiceField, formatting dates and it can't handle
custom fields and widgets properly. A good example of custom fields
and widgets that need special handling is django-ajax-selects:
http://code.google.com/p/django-ajax-selects/.

My proposal is to add display_value() method to widgets. That is, each
widget knows how to render it's value in user friendly format. For
most widgets this will just return the value. But some widgets need
special handling (DateInput, SelectMultiple, custom widgets...).

Now, a few questions:

1. Is this needed in core, is there some other functionality providing
this?
2. Is the proposed solution an acceptable way to do this?
3. What should the signature of widgets display_value be? At the
moment it is the same as render's, that is (name, value, attrs=()).
(Added with choices=() for widgets handling choices.)
4. How exactly should the display_value be rendered? One idea is to
always enclose the value in display_value.
SelectMultiple would be rendered: first_val
5. Should it be possible to say to widget that it should use
display_value when rendering? This would be a replacement for
editable=False. In this case the rendering should probably include
hidden input so that when the form is submitted, the displayed value
can be retrieved from the submit.

In my mind leaving #5 for later is a good idea, so that the first
patch would be implementing only one thing. And there are numerous
other extensions to this feature one can think of...

I have a github repository containing a WIP patch for this (http://
github.com/akaariai/django/tree/ticket10427). At the moment it really
isn't ready, but the idea can be seen in code. Implemented tests are
still from the original #10427 patch, so they are not up to date at
the moment. I hope I will get some clarification to the questions, so
that I can implement this feature.

- Anssi







-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model translation

[Anssi Kaariainen]

On Aug 8, 2:38 am, Anssi Kaariainen <akaar...@cc.hut.fi> wrote:

> I don't know if I still have the code somewhere lying around, but as I
> said it was a ugly hack that was just barely working for the easy
> cases.

If somebody is interested there is a patch available at
http://users.tkk.fi/akaariai/join.diff

Sorry, no tests, no documentation...

A sample project is available at http://users.tkk.fi/akaariai/left_join.tar.bz2

There is one example query in tester/models.py. The API is slightly
verbose... I said it was an ugly hack ;)

- Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Model translation

[Anssi Kaariainen]

On Aug 7, 11:34 pm, David Danier  wrote:

> What about "putting common data into its own model"? I like this
> solution, I even like this solution so much I tried to implement it
> several times. BUT you cannot get it to use a nice query. Most of the
> time you will need to fetch the translation inside an separate query as
> select_related() cannot fetch the translation even if the JOIN is unique
> (qs.filter(common__language='xx') will create a unique JOIN). This
> certainly could be improved.
*SNIP*
> SQL could be something like:
> SELECT ... FROM entry OUTER JOIN entry_trans ON
> (entry.id=entry_trans.entry_id AND entry_trans.language='en') WHERE ...
>
> I don't know the Django internals enough, but if this could be done
> externals model translation should be possible without much hassle.

I have hacked (for learning purposes) the Django queryset to allow
using of arbitrary joins, the API was something like this:
qs.join(qs_or_model, allow_null=False, additional_filters). If
allow_null is set to true then the query will generate left outer
join, otherwise it will generate normal join. The additional filters
will be applied to the join condition, not to where condition. The
qs_or_model could be reverse related model, or just a queryset which
will be joined using the additional_filters.

I don't know if I still have the code somewhere lying around, but as I
said it was a ugly hack that was just barely working for the easy
cases. There are plenty of corner cases, so doing it properly isn't an
easy task. However it was surprisingly easy to write the proof of
concept join method once you got the hang of the sql.query stuff. It
is well written but to my taste not sufficiently commented.

As to the model translations in core, I am of the opinion that it
shouldn't be done. There are too many different requirements. For
example I live in a country where there are two official languages, so
translations inside the table are perfectly sensible in this setting.
But we also create software which needs to be usable EU wide, which
means over ten languages easily. That means a complex model would have
somewhere around 200 db columns, which is not acceptable.

- Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Querysets with "only()" and "defer()" slower than without?

[Anssi Kaariainen]

On Aug 6, 12:09 am, Jacob Kaplan-Moss  wrote:
> If you're benchmarking this against a small dataset and an in-memory
> database like SQLite I'd fully expect to see the defer/only benchmark
> to be slower. That's because every time a QS is chained it needs to be
> copied, which is a relatively expensive operation. In a setup with
> small data, the time spent in Python is going to outweigh the time
> spent running the query in the database and sending the data over the
> wire.

A retest with:
for pk in xrange(1,5):
   user = User.objects.only("power_level").get(pk = pk)
   d = user.power_level

replaced with:
qs = User.objects.only("power_level")
for pk in xrange(1, 5):
user = qs.get(pk=pk)
d = user.power_level

# repeat for all tests.

Should remove the effect of query building. (btw why not "inplace()
function for query set if you know you won't be using the middle steps
in  chained query building?)

I have been looking into object creation speed when loading many
objects simultaneously, for my particular case running the query as
values_list took something like 5ms (sorry, I don't remember the
values and I am not at work at the moment), 50ms when constructing
instances (1500 objects in my case). The problem seems to be that for
every object created we go and check which fields the model has, which
of them come from args, which are deferred and which have default
values. It would probably be much faster to check the field
classifications once, and the bulk create the objects using the
classifications.

I did a small test for building 1500 objects in this style (only
object building, not from query set), and the result was something
like 50% faster object building. And yes, signals were sent for every
object created + default() was called if it was callable for the
field. The iterator in query makes it hard to use bulk loading style
however...

The same problem is present in row iteration when constructing objects
from the rows returned from the DB. For each row we check which select
related things we have etc. This could be checked once before starting
to iterate through the rows and then use the calculated values each
time when building the object from the row.

- Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django.db.models.Options contribute_to_class uses default connection instead of using DATABASE_ROUTERS

[Anssi Kaariainen]

As a related problem the manage.py validate seems to do the same thing
-- that is import the default connection and do any validation using
it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Running doc tests in Django's test suite

[Anssi Kaariainen]

I am trying to run some doc tests, but can't figure out how.
Specifically I would like to run the doc tests in regressiontests/
forms/widgets.py.

Running "./runtests.py --settings=test_sqlite forms" from the tests
directory it runs the unit tests (changing them results in failures)
but not the doc tests (no failures if changed). I have tried all kinds
of combinations like forms.widgets, forms.widgets_tests
forms.tests.widgets_tests as the last argument... but I just can't
figure out how to run them. So, could someone please help me?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Last call: #11863 (Model.objects.raw)

[Anssi Kaariainen]

On Dec 16, 4:34 pm, "Sean O'Connor"  wrote:
> Nice work Russ!  Got to love when something goes from "nice to have" to
> "done".
>
> Anssi, I don't think I understand your use case.  Even if an unmanaged model
> doesn't have a literal table behind it, it needs something which at least
> resembles a table (i.e. a view) to query against.  Otherwise the ORM will
> generate errors regardless of the behavior of .raw().

If you have a model which will be populated ONLY using raw queries,
then you don't need a backing view or table. And the use case is
creating something resembling a database view purely in Django.

> To answer your question, raw() determines what fields are populated by the
> names of the columns returned by the database cursor.  Accordingly, if you
> want to pull different fields using different queries, you probably do so
> using subqueries in one big SQL statement.  As long as the field names
> returned by the query match the field names in the model or you provide a
> translations parameter to describe which query fields go to which model
> fields it should work.

But if I don't provide some of the field names in the select clause,
and try to access a field that isn't included in the query, I will get
a ProgrammingError: db table not found.

> As far as allowing users to define raw queries for each field to allow them
> to be deferred, this is way outside the scope of this patch.  The goal of
> .raw() was to provide some relatively simple syntactic sugar to make a
> common class of raw queries easier.  It was not intended to completely
> replace all possible use cases for doing raw queries using a cursor.

I am not suggesting this. What I would like to have is something like
foo.field.is_deferred(). I don't think there is any easy way to test
this currently. This could come handy in a template for example. You
could use the same template for objects fetched with different raw
queries, and skip deferred fields when showing data about the object.

I haven't done any Django coding, but is_deferred() seems something
that I might be able to do. I am not sure if this is something that is
needed, though.

Anssi Kääriäinen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Last call: #11863 (Model.objects.raw)

[Anssi Kaariainen]

On Dec 16, 2:51 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> On Wed, Dec 16, 2009 at 7:56 PM, Jeremy Dunck <jdu...@gmail.com> wrote:
> > On Dec 15, 2009, at 11:16 PM, "Sean O'Connor"
> > <sean.b.ocon...@gmail.com> wrote:
>
> >> In regard to the deferred fields option, I'll let Jacob speak for
> >> his view but I've approached such functionality as "nice to have"
> >> for the patch since its not critical to the patch being useful.
> >> Personally I haven't had the time to figure it out and implement it
> >> so my original patch didn't include it.
>
> > I like the idea of the deferred fields, but if we don't implement it
> > now, people may come to rely on the AttributeError so that we can't
> > add deferred later. Perhaps a note in the docs stating our intent to
> > add deferreds would suffice?
>
> No need for workaround docs - I've just uploaded an RC3 patch that
> implements deferred fields.
>
> The one gotcha on this patch is that it now requires that you request
> the primary key when you retrieve an object. That is, you can't just
> run::
>
> Author.objects.raw('SELECT firstname, lastname FROM author')
>
> You must now include the pk:
>
> Author.objects.raw('SELECT id, firstname, lastname FROM author')
>
> If you don't, you get an exception. Unfortunately, it's an exception
> after the SQL has been executed, but that's the only way to know
> exactly which columns have been requested.
>
> This is slightly more restrictive than Jacob's RC2 patch - but I think
> the RC3 behaviour is preferable. The primary key value is a fairly
> essential part of the Django infrastructure. In RC2, if you retrieved
> an Author with firstname and lastname, then saved the object, you
> would get a new object in the database. RC3 avoids this because the
> deferred object has the right primary key.
>
> If the price of avoiding surprises like this is forcing the PK to be
> retrieved, I think it's a price worth paying. If you really can't
> afford to have the PK retrieved, then I'd argue you aren't retrieving
> a Django object; you can still call on raw SQL cursors to accommodate
> those use cases.

One use case where deferred fields aren't so nice is when creating
models which don't have any backing tables in the db. That is, models
with managed = False. These models would be the Django equivalent of
views. In these cases trying to access the field, even for testing if
it is None, would result in db query and an exception. And probably in
aborted transaction, too.

Using raw() as a way to perform view operations (complex joins etc.)
is the first use case I though of when I saw this. Anyways, using
default or None as a value isn't good either. How do you know if you
got that from the DB or not? A nice way to test which fields the model
were populated and marking the non-populated fields as deferred would
be optimal in my opinion. One use case where you don't necessary know
which fields are populated and which ones aren't is when you have
multiple raw() queries defined populating different fields of the
model.

Anssi Kaariainen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Public method for getting model field names in order of definition

[Anssi Kaariainen]

> Thanks for the example, but that's not a ModelForm.
>
> Richard

Another try, view.py:

from django.forms.models import model_to_dict

def view(request):
data = Foo.objects.all()[0]
print data.start
form = Example(data=model_to_dict(data))
return render_to_response('t.html', {'form': form})

Where Example is a ModelForm for model Foo.

Seems like there is no easy way to get access to the initial data of a
field in a template. Example(instance=foo) will only populate the
forms initial dict but not data. Should there be a similar property
for initial in BaseForm as there is for data?

Anssi Kääriäinen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=.

Re: Public method for getting model field names in order of definition

[Anssi Kaariainen]

Here is a working example. I am using svn version of Django, but IIRC
this works also in 1.0.

views.py:

from django.shortcuts import render_to_response
from django import forms

class Example(forms.Form):
field1 = forms.CharField()
field2 = forms.IntegerField(label='Labeled')

def view(request):
data = {'field1': 'Foo', 'field2': 10}
form = Example(data=data)
return render_to_response('t.html', {'form': form})

t.html:

{% for field in form %}
  {{ field.label }}{{field.data}}
{% endfor %}



On Nov 23, 2:14 am, Richard Laager <rlaa...@wiktel.com> wrote:
> On Sat, 2009-11-21 at 05:57 -0800, Anssi Kaariainen wrote:
> > If I am not completely mistaken you can use your ModelForm with
> > field.label and field.data to get read-only view of the model.
>
> I was trying to do something like this today and didn't have any luck.
> Do you have a pointer to a working sample?
>
> Richard
>
>  signature.asc
> < 1KViewDownload

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=.

Re: Public method for getting model field names in order of definition

[Anssi Kaariainen]

On Nov 21, 6:25 am, Rob Hudson  wrote:
> But if you wanted to redisplay that information back to the user in a
> read-only form, there is no iterative way to do so (as far as I know).
>  Instead you must specifically "hard code" each field:
>
>     
>         Field 1
>         {{ profile.field1 }}
>         
>     

If I am not completely mistaken you can use your ModelForm with
field.label and field.data to get read-only view of the model.

Anssi Kääriäinen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=.

Re: Continuous Integration command

[Anssi Kaariainen]

On Oct 18, 8:08 pm, berto  wrote:
> Sounds like you're interpreting what I'm looking as a feature, a
> bug.  :)  I want to write tests and see them fail continually until I
> have written the code that makes them pass.

Is it possible to autorun only the failing tests? It would be very
useful (at least for me) if the following was supported:

1) run all the tests.
2) on file change, run tests that failed in step 1.
3) when no tests fail in step 2, run all the tests again. If failures,
start from step 1 again. If no failures, print "Completed".



--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

manage.py reset and custom sql

[Anssi Kaariainen]

Hello all,

The problem I am trying to solve is this: I have defined some views
and corresponding models with managed = False. Now when I issue
manage.py reset I get an error because the views block dropping the
tables. I need to manually drop the views before I issue manage.py
reset.

I am thinking of implementing a patch for this. This would be my first
patch for Django. The idea for the patch is simple: now there is
sqlcustom, which looks for a file in "/sql/.sql"
for each model. I would add sqlcustomdrop (better name needed?)
command which would look for sql in "/sql/
.drop.sql". This would be run before any django generated
drop table commands would be run.

Is there some nice way to achieve this already in Django? And is this
something that would be useful for Django core? Any feedback would be
nice before I start working on this.

Anssi Kääriäinen
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Two simple to fix bugs in 1.1 RC

[Anssi Kaariainen]

Hello all,

1)

If using postgresql with autocommit = True, and a postgresql version
that supports autocommit, first save of a model will fail if it is the
first query ran. ("ProgrammingError: no results to fetch").

The problem is that the generated query will not contain "RETURNING
id" because when it is generated the database version is not known
(version is sniffed at first connect). When the query is executed
Django expects the query to contain the "RETURNING id" part because
the connection has been established and thus
connection.features.can_return_id_from_insert is set to True.

This is easy to fix: just add try-except block to django/db/models/sql/
subqueries.py line 324. This is not a good solution, but it will work
until #10509 is fixed.

2)

Some of the manage.py commands will not work if there is proxy models,
for example the following will fail:

test_proxy/models.py:
class Foo:
field = models.IntegerField()

class Bar(Foo)
class Meta:
proxy = True

$ python manage.py syncdb
$ python manage.py reset test_proxy
The full error: table "foo" does not exist

$ python manage.py sqlreset test_proxy
BEGIN;
DROP TABLE "foo";
DROP TABLE "foo";
-- Note duplicate drop table!
CREATE TABLE "foo" (
"id" serial NOT NULL PRIMARY KEY,
"field" integer NOT NULL
)
;
CREATE TABLE "foo" (
)
;
COMMIT;

The reason is that proxy models are handle as if they had a database
table.

I have solved this one by modifying the signature of
django.db.models.get_models(self, app_mod=None): to get_models(self,
app_mod=None, include_proxy=True) and using include_proxy=False in
django.core.management commands where necessary. This has worked for
me but maybe there could be a better fix for this. I have made a
ticket about this some time ago. (#11428)

I just wanted to bring these two simple to fix bugs in your attention
so that they wont slip into the 1.1 release.


Anssi

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

first insert on connection fails (psycopg2, postgresql version__gte 8.2)

[Anssi Kaariainen]

Hello all,

I think I found a bug in django SVN when using psycopg2 and postgresql
version > 8.1. The problem is simple to reproduce:

class Foo():
   pass

$ python manage.py shell
>>> Foo().save() # Fails
django/db/backends/__init__.pyc in fetch_returned_insert_id(self,
cursor)
--> 171 return cursor.fetchone()[0]
ProgrammingError: no results to fetch
>>> Foo().save() # Success

So the query must be the absolutely first query to run. Psycopg2 gets
the version number of postgresql from the connection. But when the
first query is transformed to SQL the version number is not jet
correct and so the query will not contain "RETURNING id". But when the
query is executed, the version number is set up and thus execute_sql
expects the query to contain the RETURNING id part.

I did not create a ticket as I am not sure if this is covered in
#10509 or not.

Anssi Kääriäinen

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---