Re: Dropping django.utils.simplejson

[Florian Apolloner]

Hi,

I am for number 2 too, but don't forget that's deprecation in 1.5 and 1.6 
and removal in 1.7

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/mzYEOlCKfHkJ.
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.

[GSoC 2012] Enhanced contrib.auth

[Stratos Moros]

You can read the proposal nicely formatted here:  
https://gist.github.com/8dd9fb27127b44d4e789


GSoC 2012 Proposal - enhanced contirb.auth
==

Hello, my name is Stratos Moros and I am a Computer Science student in the  
University of Piraeus in Greece.


I would like to participate in Google Summer of Code with Django, working  
on an enhanced contrib.auth.


Goals
-

-   Long term solution

	The proposed replacement doesn't aim at just improving some of the  
current limitations of contrib.auth (e.g. increasing the email field  
size), but at providing a long term solution.


-   Backwards compatibility

	The new contrib.auth will be 100% backwards compatible with the current  
implementation. Developers updating their existing Django installation  
will have the same features available, without having to update their code  
or undergo a database migration.


-   Separation of concerns

	The concepts of identity, authentication and authorization should not be  
tightly coupled by default. Developers will be able to mix and match  
schemes if they want, or use a more integrated approach otherwise.


-   Extensibility

	It's impossible to cover all existing and future authentication /  
authorization schemes. Developers who have needs that aren't covered by  
Django should be able to extend contrib.auth by writing their own or using  
third party user models. Other apps that need to interact with users (e.g.  
a commenting app) will be able to interact with them without knowing the  
specific implementation.


-   Batteries included

	Developers will not be required to implement their own authentication or  
authorization schemes for the common cases. Contrib.auth will have one or  
more built in user models ready for production.


-   Admin compatibility

	Contrib.admin is one of the things that make Django great. It should be  
easy for developers to make their user models accessible through the admin  
interface.


Terminology
---

In order to distinguish between Django's users, a website's users and the  
proposed concept of a user, the terms "developer", "visitor" and "user"  
are used respectively.



Implementation
--

The new contrib.auth will serve three primary functions:

-   Assist developers in writing custom user models.
-   Provide built in user models.
-   Provide a way for developers to interact generically with user models.

The new contrib.auth will allow developers to specify multiple user  
models. A new setting will be introduced called `USER_MODELS` which will  
be a tuple of strings. Each string's format will be `'%(app).%(model)'`,  
similarly to how `AUTH_PROFILE_MODULE` is currently defined. This setting  
will look something like:


USER_MODELS = (
'auth.EmailUser',
'myapp.CustomUser',
# ...
)

### Separation of concerns and the user contract

A user model will be a regular model that fulfills a predefined contract.  
Developers will be able to write their own user models in their  
applications and register them through the `USER_MODELS` setting. Any  
model that fulfills the user contract and is specified in `USER_MODELS`  
will be considered a valid user model. The contract will be subdivided in  
three subcontracts that will be concerned with identity, authentication  
and authorization.


 Identity

The identity contract will answer the "who are you" question for a user  
model. This could be anything from a twitter handle to a biometric  
identifier, or anything else that can uniquely identify a user in a user  
model. To fulfill the identity contract the user model will have to:


-   Implement an `identity` method.

	This method must return a string that uniquely represents a user in a  
user model.


-   Implement a `get_by_identity` method on the model's default manager.

	This method must accept a string representing a user, as returned by the  
`identity` method, and return the either a user object, if it finds one,  
or `None` otherwise.


-   Implement a `__unicode__` method.

	This method must return a string representation of a user that is  
suitable for displaying on the frontend. This will not be required to be  
unique across all users in a user model.


 Authentication

The authentication contract will be concerned with verifying that the user  
is indeed who he claims to be. Again, this could be anything from a  
password to a hardware dongle. To fulfill the authentication contract the  
user model will have to:


-   Implement an `is_authenicated` method.

	This method must accept a request. Contrary to the current  
implementation, the `is_authenticated` method will not always return  
`True`. It is up to the implementation to decide whether the user is  
actually authenticated.


-   Implement an `is_authenticated_by` method.

	This method must accept any arguments

Re: Dropping django.utils.simplejson

[Alex Ogier]

It seems like everyone besides me agrees on option #2 so I implemented it
in #18023  (
https://github.com/ogier/django/compare/remove-simplejson ). At the same
time, I want to reiterate my support for option #1: not deprecating the
module and leaving the shim in for the foreseeable future. If simplejson is
available on the system, and particularly if it has been compiled with C
extensions, then there is a significant performance gain to be had, so why
not continue to take advantage of that in all the places that django
serializes to json?

Best,
Alex Ogier

On Fri, Mar 30, 2012 at 4:13 AM, Florian Apolloner wrote:

> Hi,
>
> I am for number 2 too, but don't forget that's deprecation in 1.5 and 1.6
> and removal in 1.7
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/mzYEOlCKfHkJ.
>
> 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.
>

-- 
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.

Re: [GSoC 2012] Enhanced contrib.auth

[Tom Evans]

On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros  wrote:
> You can read the proposal nicely formatted here:
> https://gist.github.com/8dd9fb27127b44d4e789

Hi Stratos

It's a long proposal, so this is a brain dump of bits that I find
interesting/worrisome.

I'm sure you've followed the recent threads on the topic. The (wildly)
different solutions garnered from those long threads are all listed on
this wiki page:

  https://code.djangoproject.com/wiki/ContribAuthImprovements

I don't think this proposal ties in with any of them? Your proposal
involves multiple user models, whilst none of them do.

Login:

Where have auth backends gone in your plan? Why do user objects have a
login method, login should be distinct from user objects, otherwise
login is coupled to a user object, and you cannot log in to the same
user using different authentication techniques.

It is common these days to provide multiple ways of authenticating to
your users, if I authenticate by smartcard, user/password, Facebook
auth, SAML federation, or a "remember me" signed auth cookie, I should
still get the same user object. The choice of authentication is
irrelevant.

More to the point, it should be *my* choice. Forcing authentication
into the user model removes that choice, or requires us to have N user
models per user, one per auth method.


Authentication mixins:

This goes to the above point; if I have to mixin an authentication
class to my user object (adding the required login() + others
methods), it means I can only have one authentication mechanism for a
particular user model.


Deprecating user profiles:

The purpose of user profiles is to provide a place for a pluggable app
to store its own information about a user. Adding a pluggable app
should not mean having to add fields to your user model, but with no
user profiles, that's what is suggested.

Once you have a significant number of pluggable apps, you could have a
User model with a crazy number of fields - I can envisage scenarios
where you have over 100 fields. This makes doing anything with the
user model slower. Furthermore, storage for each field is now required
for every user, whilst with a pluggable profile, it would only exist
if the user utilizes that app.

Cheers

Tom

-- 
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.

Re: [GSoC 2012] Enhanced contrib.auth

[Stratos Moros]

On Fri, 30 Mar 2012 17:35:16 +0300, Tom Evans   
wrote:


On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros   
wrote:

You can read the proposal nicely formatted here:
https://gist.github.com/8dd9fb27127b44d4e789


Hi Stratos

It's a long proposal, so this is a brain dump of bits that I find
interesting/worrisome.


Hi Tom.

I'm answering your 3 questions together because they are related to each  
other.


In my proposal, a user model represents an authentication/authorization  
scheme. This is why you have to mixin the authentication scheme directly  
in the model. All other information, such as first_name, last_name etc.  
should live in the user's profile.


The idea isn't to remove custom profiles, but to let developers control  
where they're used. The example I provided about adding custom profiles  
was rather bad. The way I expect most developers to add a fields to a user  
is:


class CustomUser(SomeMixins):
profile = models.ForeignKey(UserPorfile)

This way you can allow your frontend users to log in with, say, either  
with username & password or openid and have a single profile between them,  
while allowing your backend users to login with credentials from an LDAP  
server and have a different profile for them.


This is why authentication backends are deprecated. If you can't specify  
which authentication mechanism is used for each user model, you can't  
easily accomplish the above scenario. You would have to have a single  
table to represent the two different profiles and you would somehow make  
sure that a user trying to log in with facebook doesn't go through the  
LDAP server.


This is also why the identity in the user model is a method and not a  
field. If you want a single user to be authenticated in multiple ways, you  
can override the identity method and return the same value.


Perhaps the profile field should be made part of the user contract, but  
this would be an annoyance in cases where you don't want to store any  
additional information about the users, but use them only for  
authorization purposes (ie. I don't care about his info, I just want to  
know if he can access this page).


Having login and logout be part of the user model was one of the things  
that I wasn't sure about. The reason I put them in the user model is to  
decouple the whole process from the session. This way an authentication  
scheme that doesn't want to use the session to store a logged in user can  
do so. The common case would obviously be to store them in the session, so  
I included the SessionAuthenticationMixin.


The same goes for authorization. Inheriting from a mixin implementing the  
authorization contract would probably add a foreign key to the table  
storing the permissions plus a few methods to query it. This way you can  
handle different user models' permissions in completely different ways.


Thanks for the feedback. I hope I've answered your questions.

--
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.

Re: Dropping django.utils.simplejson

[Łukasz Rekucki]

On 30 March 2012 13:04, Alex Ogier  wrote:
> At the same time, I want to reiterate my support for option #1: not 
> deprecating the
> module and leaving the shim in for the foreseeable future. If simplejson is
> available on the system, and particularly if it has been compiled with C
> extensions, then there is a significant performance gain to be had, so why
> not continue to take advantage of that in all the places that django
> serializes to json?

I agree this is a valid concern and I think it should be mentioned in
release notes. If you want more performance, then option #3 (anyjson)
would actually be better, but I don't think it should be Django's
concern to choose the best JSON package for you (we don't do that for
XML). Instead, imho, Django should provide an ability to pass a custom
JSON encode/decoder to all APIs that require it, so you can decide
about it at the project level.

-- 
Łukasz Rekucki

-- 
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.

Allowing Reverse, Single Inlines in Admin

[Tyler Kocheran]

Presently, there's not a way without altering models to be able to have 
inline models if dependencies are declared on the "owning" class. Allow me 
to explain with code:

class Person(models.Model):

address = models.OneToOneField("Address")

class Monument(models.Model): 
address = models.OneToOneField("Address")

class Sighting(models.Model):
address = models.OneToOneField("Address")

class Address(models.Model):
name = models.CharField(...)
street_address = models.CharField(...)


The goal with this code is that a `Person` owns an `Address` like a 
`Monument` owns an `Address` like a `Sighting` owns an `Address`. There's 
really no reason for an `Address` to know of itself what it is owned by, it 
could be owned by multiple different objects. The lookup needs to happen 
from the owner.

When attempting to make inlines for these types of relations, an error is 
thrown:

class AddressInline(admin.TabularInline):
model = Address
fields = ('street_address',)

class SightingAdmin(admin.ModelAdmin):
inlines = (AddressInline,)


 Here's the error which is thrown by a *similar* real example: 
http://pastebin.com/rQreWCwY



IMHO, inlines should work regardless of which side the relationship is 
declared on. Can I submit this for a feature request? 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WOdxe54kb1kJ.
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.

Re: Allowing Reverse, Single Inlines in Admin

[ptone]

On Friday, March 30, 2012 11:44:29 AM UTC-7, Tyler Kocheran wrote:

 There's really no reason for an `Address` to know of itself what it is 
> owned by, it could be owned by multiple different objects. 
>

Not if you are using a OneToOneField...

I think you are just looking for a FK to an address model on each of your 
other models.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/1qyvaXw39QsJ.
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.

Re: Allowing Reverse, Single Inlines in Admin

[Tyler Kocheran]

I mean "multiple types of objects." Basically, in the db, it looks a bit
like this:

create table address(id int primary key auto increment, name text, address
text);
create table person(id int primary key auto increment, first_name
varchar(30),
last_name varchar(30), address_id int foreign key references
"address"("id"));
create table sighting(id int primary key auto increment, name varchar(30),
address_id int foreign key references "address"("id"));


What I mean to say is that "Address" doesn't need to know in the database
that its owned by something else, that notion of ownership is indicated
elsewhere. Sure, in Django, you could climb "Address.person" to get to the
owning person. In any case, that's somewhat beyond the point.

The real point is that I shouldn't be getting errors if I want to have a
OneToOneField inline of an Address on a Person. No matter what side the
relation is declared on, inlines should just work™. Maybe it's not the best
idea for a data model, but if a user has this requirement, Django should be
flexible enough to meet it, and I do think it's a good idea.

Thanks,
 - TK



On Fri, Mar 30, 2012 at 1:49 PM, ptone  wrote:

>
>
> On Friday, March 30, 2012 11:44:29 AM UTC-7, Tyler Kocheran wrote:
>
>  There's really no reason for an `Address` to know of itself what it is
>> owned by, it could be owned by multiple different objects.
>>
>
> Not if you are using a OneToOneField...
>
> I think you are just looking for a FK to an address model on each of your
> other models.
>
> -Preston
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/1qyvaXw39QsJ.
> 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.
>

-- 
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.

Re: Dropping django.utils.simplejson

[Alex Ogier]

I did some timing tests.
https://code.djangoproject.com/ticket/18023#comment:5

An order of magnitude difference in JSON serialization time corresponds to
an 8% change in total serialization time for a complex model, and 5 deeply
nested model instances can be serialized in < 2 ms. It might be a little
different depending on how deeply your models are related, but it convinced
me that splitting hairs over the JSON serializer isn't worth it. I had the
idea in my head that serialization might be a bottleneck in the same way
that template rendering is, but I realize now it's very different. Heavily
nested and unoptimized templates thrash the disk and change a 10ms response
into a 100ms response. Shoddy JSON serializers might thrash the heap, or
make the GC work overtime, but it's all in memory so the worst that happens
is that a 10ms response becomes a 12ms response. It's just not worth
worrying about.

Best,
Alex Ogier

On Fri, Mar 30, 2012 at 2:02 PM, Łukasz Rekucki  wrote:

> On 30 March 2012 13:04, Alex Ogier  wrote:
> > At the same time, I want to reiterate my support for option #1: not
> deprecating the
> > module and leaving the shim in for the foreseeable future. If simplejson
> is
> > available on the system, and particularly if it has been compiled with C
> > extensions, then there is a significant performance gain to be had, so
> why
> > not continue to take advantage of that in all the places that django
> > serializes to json?
>
> I agree this is a valid concern and I think it should be mentioned in
> release notes. If you want more performance, then option #3 (anyjson)
> would actually be better, but I don't think it should be Django's
> concern to choose the best JSON package for you (we don't do that for
> XML). Instead, imho, Django should provide an ability to pass a custom
> JSON encode/decoder to all APIs that require it, so you can decide
> about it at the project level.
>
> --
> Łukasz Rekucki
>
> --
> 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.
>
>

-- 
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.

Re: Dropping django.utils.simplejson

[Mikhail Korobov]

Standard python 2.6 json is a bundled and cleaned up simplejson without C 
extension and pre-26 compatibility - even if json serialization is not a 
common bottleneck why make things worse? Simplejson and python 2.6 json are 
arguably the same libraries, I think this is like choosing between 
cStringIO vs StringIO. 

суббота, 31 марта 2012 г. 3:03:00 UTC+6 пользователь Alex Ogier написал:
>
> I did some timing tests.  
> https://code.djangoproject.com/ticket/18023#comment:5
>
> An order of magnitude difference in JSON serialization time corresponds to 
> an 8% change in total serialization time for a complex model, and 5 deeply 
> nested model instances can be serialized in < 2 ms. It might be a little 
> different depending on how deeply your models are related, but it convinced 
> me that splitting hairs over the JSON serializer isn't worth it. I had the 
> idea in my head that serialization might be a bottleneck in the same way 
> that template rendering is, but I realize now it's very different. Heavily 
> nested and unoptimized templates thrash the disk and change a 10ms response 
> into a 100ms response. Shoddy JSON serializers might thrash the heap, or 
> make the GC work overtime, but it's all in memory so the worst that happens 
> is that a 10ms response becomes a 12ms response. It's just not worth 
> worrying about.
>
> Best,
> Alex Ogier
>
> On Fri, Mar 30, 2012 at 2:02 PM, Łukasz Rekucki wrote:
>
>> On 30 March 2012 13:04, Alex Ogier  wrote:
>> > At the same time, I want to reiterate my support for option #1: not 
>> deprecating the
>> > module and leaving the shim in for the foreseeable future. If 
>> simplejson is
>> > available on the system, and particularly if it has been compiled with C
>> > extensions, then there is a significant performance gain to be had, so 
>> why
>> > not continue to take advantage of that in all the places that django
>> > serializes to json?
>>
>> I agree this is a valid concern and I think it should be mentioned in
>> release notes. If you want more performance, then option #3 (anyjson)
>> would actually be better, but I don't think it should be Django's
>> concern to choose the best JSON package for you (we don't do that for
>> XML). Instead, imho, Django should provide an ability to pass a custom
>> JSON encode/decoder to all APIs that require it, so you can decide
>> about it at the project level.
>>
>> --
>> Łukasz Rekucki
>>
>> --
>> 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.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/edityP87yQQJ.
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.

Re: Allowing Reverse, Single Inlines in Admin

[ptone]

On Friday, March 30, 2012 1:58:08 PM UTC-7, Tyler Kocheran wrote:
>
>
> The real point is that I shouldn't be getting errors if I want to have a 
> OneToOneField inline of an Address on a Person. No matter what side the 
> relation is declared on, inlines should just work™. Maybe it's not the best 
> idea for a data model, but if a user has this requirement, Django should be 
> flexible enough to meet it, and I do think it's a good idea.
>>
>>
>>
>
Now that I understand - I agree.  Looking at this briefly - it would be a 
matter of making the notion of "parent_model" in inlineformset_factory be 
valid on either side of the OneToOne.

This would be some form of letting SingleRelatedObjectDescriptor be as 
valid as a fk in django.forms.models._get_foreign_key()

This actually has very timely bearing on the auth discussion believe it or 
not...

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/OvzZO5iQBl8J.
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.

Re: Allowing Reverse, Single Inlines in Admin

[Tyler Kocheran]

YUSS. Yeah, it's just been kind of frustrating trying to get this to work
lately. I designed a whole model set, then realized that it won't work with
admin :) 1.4.1?

Thanks,
 - TK



On Fri, Mar 30, 2012 at 3:09 PM, ptone  wrote:

>
>
> On Friday, March 30, 2012 1:58:08 PM UTC-7, Tyler Kocheran wrote:
>>
>>
>> The real point is that I shouldn't be getting errors if I want to have a
>> OneToOneField inline of an Address on a Person. No matter what side the
>> relation is declared on, inlines should just work™. Maybe it's not the best
>> idea for a data model, but if a user has this requirement, Django should be
>> flexible enough to meet it, and I do think it's a good idea.
>>>
>>>
>>>
>>
> Now that I understand - I agree.  Looking at this briefly - it would be a
> matter of making the notion of "parent_model" in inlineformset_factory be
> valid on either side of the OneToOne.
>
> This would be some form of letting SingleRelatedObjectDescriptor be as
> valid as a fk in django.forms.models._get_foreign_key()
>
> This actually has very timely bearing on the auth discussion believe it or
> not...
>
> -Preston
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/OvzZO5iQBl8J.
>
> 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.
>

-- 
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.