Re: API for introspecting models
Very interesting / exciting. I'm definitely +1 on this project - I definitely have some of the "break hard" projects that Russell is talking about and I'd love to have a more straightforward and sustainable way to do introspection. Let me know how I can help. On Fri, Sep 23, 2011 at 10:47 PM, Russell Keith-Magee wrote: > On Fri, Sep 23, 2011 at 6:10 PM, sebastien piquemal wrote: >>> So - it's one of those things that *should* be documented and >>> fomalized; it's just waiting on someone with the spare time to do the >>> job. >> >> Sounds good ! Any estimation on how big is the cleaning task ? I know >> documentation task can go forever :) > > About as long as this piece of string that I'm holding. Oh, wait - you > can't see the string? Let me hold it up for you... :-) > > Seriously -- I can't really answer this. It's not a completely trivial > task, but it's not complex on the order of "multi-db" or "no-sql > support" either. The first step really is an audit -- a rough cut at > documenting everything that is there at the moment. Once we have that, > we can look at how the existing API is being used, and evaluate the > cleanup opportunities. > > Once that's done, we'll be in a much better position to evaluation how > much work is involved. > >> And what about the extra features I suggested ? A more user-friendly >> way to get all -data- fields (including m2m, excluding pointers), an >> easy way to get the name of the pk field of the first parent. > ... >> Or did I miss some methods/properties from the _meta API ? > > Off the top of my head, I can't answer this. It's *possible* that > there might be some way to do this, but I'd need to go digging to work > out for sure, and I can't refer to the documentation to find out > easily :-) > > However, I wouldn't be at all surprised if it isn't possible. The > _meta API is mostly designed for Django's own internal needs, and > Django needs to make a very clear distinction between fields and > m2m's, forward and reverse fields, and so on; hence the distinctions > that exist in the current API. "Iterating over all fields" doesn't > make much sense from an internal perspective, because different types > of fields need to be handled differently. Similarly, the "hidden" _ptr > fields might not be important from a public visibility perspective, > but they're very important from an internal perspective. > > That said, just because Django doesn't have a use for the API doesn't > mean it wouldn't be useful. If you can propose a clean way to augment > the _meta API to provide this sort of capability, I don't see any > fundamental reason why it shoudn't be included. > > Yours, > Russ Magee %-) > > -- > 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. > > -- Justin Holmes Head Instructor, SlashRoot Collective SlashRoot: Coffee House and Tech Dojo 60 Main Street New Paltz, NY 12561 845.633.8330 -- 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: API for introspecting models
Ok :) Honestly, I don't have that much time, so I can't promise to look actively into that (but I guess that's no big deal). Of course, if Justin helps it sounds like a more reasonable task :) Anyways, I could perfectly start with the first step : > a rough cut at documenting everything that is there at the moment. Which would allow me to have a better knowledge at what the API has to offer exactly, and therefore give me a clearer idea on how to implement those "gimme all the fields" functions. That's for the theory ! > If you can propose a clean way to augment the _meta API to provide this sort > of capability That's for the practice ! What would be an "unclean" way for you ? Are you talking about (a) the beauty of the API itself, or (b) its implementation ? Assuming (a) : from what I understood from your previous message, _meta API's fate is -one day- to be a public API that everybody could use in peace and harmony, right ? So with that in mind ... is it clean to have methods for public use and and methods for internal use in the same object ? -> I guess in that case the best would be to make private all methods for internal use, and public all methods for public API, but that's probably not realistic since that would require massive renamings. > That said, just because Django doesn't have a use for the API doesn't mean it > wouldn't be useful. >From my perspective (and Justin's) it would be very useful !!! And I am pretty sure we are not the only ones ! Cheers, Sébastien On Sep 24, 10:41 am, Justin Holmes wrote: > Very interesting / exciting. I'm definitely +1 on this project - I > definitely have some of the "break hard" projects that Russell is > talking about and I'd love to have a more straightforward and > sustainable way to do introspection. > > Let me know how I can help. > > On Fri, Sep 23, 2011 at 10:47 PM, Russell Keith-Magee > > > > > > > > > > wrote: > > On Fri, Sep 23, 2011 at 6:10 PM, sebastien piquemal > > wrote: > >>> So - it's one of those things that *should* be documented and > >>> fomalized; it's just waiting on someone with the spare time to do the > >>> job. > > >> Sounds good ! Any estimation on how big is the cleaning task ? I know > >> documentation task can go forever :) > > > About as long as this piece of string that I'm holding. Oh, wait - you > > can't see the string? Let me hold it up for you... :-) > > > Seriously -- I can't really answer this. It's not a completely trivial > > task, but it's not complex on the order of "multi-db" or "no-sql > > support" either. The first step really is an audit -- a rough cut at > > documenting everything that is there at the moment. Once we have that, > > we can look at how the existing API is being used, and evaluate the > > cleanup opportunities. > > > Once that's done, we'll be in a much better position to evaluation how > > much work is involved. > > >> And what about the extra features I suggested ? A more user-friendly > >> way to get all -data- fields (including m2m, excluding pointers), an > >> easy way to get the name of the pk field of the first parent. > > ... > >> Or did I miss some methods/properties from the _meta API ? > > > Off the top of my head, I can't answer this. It's *possible* that > > there might be some way to do this, but I'd need to go digging to work > > out for sure, and I can't refer to the documentation to find out > > easily :-) > > > However, I wouldn't be at all surprised if it isn't possible. The > > _meta API is mostly designed for Django's own internal needs, and > > Django needs to make a very clear distinction between fields and > > m2m's, forward and reverse fields, and so on; hence the distinctions > > that exist in the current API. "Iterating over all fields" doesn't > > make much sense from an internal perspective, because different types > > of fields need to be handled differently. Similarly, the "hidden" _ptr > > fields might not be important from a public visibility perspective, > > but they're very important from an internal perspective. > > > That said, just because Django doesn't have a use for the API doesn't > > mean it wouldn't be useful. If you can propose a clean way to augment > > the _meta API to provide this sort of capability, I don't see any > > fundamental reason why it shoudn't be included. > > > Yours, > > Russ Magee %-) > > > -- > > 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 > > athttp://groups.google.com/group/django-developers?hl=en. > > -- > Justin Holmes > > Head Instructor, SlashRoot Collective > SlashRoot: Coffee House and Tech Dojo > 60 Main Street > New Paltz, NY 12561 > 845.633.8330 -- You received this message because you are subscribed to the Google Groups "Djang
Re: API for introspecting models
It might be worth it to look at this existing effort to document _meta: http://readthedocs.org/projects/django-model-_meta-reference/. Simon -- 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/-/FxTT4AIHOG8J. 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: Localization on User model
On Thu, Sep 22, 2011 at 1:52 PM, Aymeric Augustin wrote: > 2011/9/22 lvella : >> What about changing this in future versions? Maybe simply a >> "true_name" field would do? Or maybe a way to customize the fields in >> the User model. > > Hi lvella, > > This issue should be viewed in the context of: > https://code.djangoproject.com/wiki/SummerOfCode2011#Enhancedauth.user > Unfortunately, this GSoC didn't happen this summer. > > The canonical ticket for this issue is > https://code.djangoproject.com/ticket/3011 — there's a lot of > background over there. > > Best regards, > > -- > Aymeric Augustin. > Another great resource on that topic is the article "Personal names around the world" [1] on the w3c's website. [1]: http://www.w3.org/International/questions/qa-personal-names Best regards, Horst -- 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.
Check-in #3 / Multiple timezone support for datetime representation
Hello, This week, I've been working on a related topic that I had missed entirely in my initial proposal: serialization. Developers will obtain aware datetimes from Django when USE_TZ = True. We must ensure that they serialize correctly. Currently, the serialization code isn't very consistent with datetimes: - JSON: the serializer uses the '%Y-%m-%d %H:%M:%S' format, losing microseconds and timezone information. This dates back to the initial commit at r3237. See also #10201. - XML: the serializer delegates to DateTimeField.value_to_string, who also uses the '%Y-%m-%d %H:%M:%S' format. - YAML: the serializer handles datetimes natively, and it includes microseconds and UTC offset in the output. I've hesitated between converting datetimes to UTC or rendering them as-is with an UTC offset. The former would be more consistent with the database and it's recommended in YAML. But the latter avoids modifying the data: not only is it faster, but it's also more predictable. Serialization isn't just about storing the data for further retrieval, it can be used to print arbitrary data in a different format. Finally, when the data comes straight from the database (the common case), it will be in UTC anyway. Eventually, I've decided to serialize aware datetimes without conversion. The implementation is here: https://bitbucket.org/aaugustin/django/compare/..django/django Here are the new serialization formats for datetimes: - JSON: as described in the specification at http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf > 15.9.1.15 Date Time String Format. - XML: as produced by datetime.isoformat(), ISO8601. - YAML: unchanged, compatible with http://yaml.org/type/timestamp.html — the canonical representation uses 'T' as separator and is in UTC, but it's also acceptable to use a space and include an offset like pyyaml does. These formats follow the best practices described in http://www.w3.org/TR/NOTE-datetime. This fix is backwards-incompatible for the JSON and XML serializers: it includes fractional seconds and timezone information, and it uses the normalized separator, 'T', between the date and time parts. However, I've made sure that existing fixtures will load properly with the new code. I'll mention all this in the release notes. Unrelatedly, I have switched the SQLite backend to supports_timezones = False, because it really doesn't make sense to write the UTC offset but ignore it when reading back the data. Best regards, -- Aymeric Augustin. On 17 sept. 2011, at 09:59, Aymeric Augustin wrote: > Hello, > > This week, I've gathered all the information I need about how the database > engines and adapters supported by Django handle datetime objects. I'm > attaching my findings. > > The good news is that the database representations currently used by Django > are already optimal for my proposal. I'll store data in UTC: > - with an explicit timezone on PostgreSQL, > - without timezone on SQLite and MySQL because the database engine doesn't > support it, > - without timezone on Oracle because the database adapter doesn't support it. > > > Currently, Django sets the "supports_timezones feature" to True for SQLite. > I'm skeptical about this choice. Indeed, the time zone is stored: SQLite just > saves the output of ".isoformat(), which includes the UTC offset > for aware datetime objects. However, the timezone information is ignored when > reading the data back from the database, thus yielding incorrect data when > it's different from the local time defined by settings.TIME_ZONE. > > As far as I can tell, the "supports_timezones" and the > "needs_datetime_string_cast" database features are incompatible, at least > with the current implementation of "typecast_timestamp". There's a comment > about this problem that dates back to the merge of magic-removal, possibly > before: > https://code.djangoproject.com/browser/django/trunk/django/db/backends/util.py?annotate=blame#L79 > > SQLite is the only engine who has these two flags set to True. I think > "supports_timezones" should be False. Does anyone know why it's True? Is it > just an historical artifact? > > > Finally, I have read the document that describes "to_python", > "value_to_string", and r"get_(db_)?prep_(value|save|lookup)". The next step > is to adjust these functions in DateFieldField, depending on the value of > settings.USE_TZ. > > Best regards, > > -- > Aymeric Augustin. > > > > On 11 sept. 2011, at 23:18, Aymeric Augustin wrote: > >> Hello, >> >> Given the positive feedback received here and on IRC, I've started the >> implementation. >> >> Being most familiar with mercurial, I've forked the Bitbucket mirror. This >> page that compares my branch to trunk: >> https://bitbucket.org/aaugustin/django/compare/..django/django >> >> I've read a lot of code in django.db, and also the documentation of >> PostgreSQL, MySQL and SQL
Re: Revisiting proxied SSL headers
On 24/09/11 01:06, Paul McMillan wrote: > CarlJM's django-secure package [4] solves this problem by requiring > the user to specify which header they want, if they need support for > this. > > Luke's concerns about the security of this setting are extremely well > founded. Enabling it when it is not needed is a very serious security > problem, and negates many of the benefits of using SSL. In contrast, > since Django doesn't support this configuration out of the box, we > have users who are losing other benefits that SSL could provide when > Django assumes all requests are insecure. The most striking example of > this is our CSRF protection, where we enforce much more rigorous > requirements on secured connections. Hmm, I hadn't thought of the security implications of 'is_secure' returning false negatives as well as false positives. We do need it to be reliable in both ways. In the comments on that ticket I had an attack scenario where getting is_secure() == True when it should have been False opened up vulnerabilities, but you have one where the reverse also opens up vulnerabilities, so we definitely need to reconsider this. Further, the one I had thought of applies to code that theoretically exists, or exists outside of Django, but your is code that is definitely within Django, which swings it the other way. It is a tricky problem, because I don't know of any perfect solution. My concern is not only that it is possible to configure incorrectly, it appears to be virtually impossible to configure correctly, as it appears to be very hard to get web servers to filter incoming headers, and so filter a X-Forwarded-Protocol=SSL header that is set by a MITM. My current thinking is that we go with your suggestion, and to cover the problem of a faked HTTPS connection that I was concerned about we just make it clear exactly which way is_secure() is unreliable, and that the main Apache instance must be configured to do the redirection from HTTP to HTTPS if needed. (This is already indicated here: https://docs.djangoproject.com/en/dev/topics/security/#ssl-https but that would need re-working in light of your proposed changes). Luke -- I never hated a man enough to give him his diamonds back. (Zsa Zsa Gabor) Luke Plant || http://lukeplant.me.uk/ -- 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: new feature idea: even and odd forloop iteration variables
Hi skazhy,
> I've been working with Django for a while now, but today I decided to
> make a first contribution to Django that would make templates less
> ugly by adding these two values to loop_dict (in django/template/
> defaulttags.py):
>
> loop_dict['even'] = (i %2 == 0)
> loop_dict['odd'] = (i %2 != 0)
>
> Using {% if forloop.even %} would be more clear and readable than {%
> if forloop|divisibleby:"2" %}.
> As I am new to working *on* Django I don't know the history of this
> idea (if there is one) and the correct way of sending patches, all
> comments (and corrections!) are appreciated!
I agree with Russell - this overlaps completely with 'cycle' or
'divisibleby', and we prefer Only One Way To Do It.
Thanks for the idea though,
Luke
--
I never hated a man enough to give him his diamonds back. (Zsa Zsa
Gabor)
Luke Plant || http://lukeplant.me.uk/
--
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: confusing things in Trac UI (was: Design decision for #1625...)
On 21/09/11 10:40, Stephen Burrows wrote: > Just thought it might be worth mentioning in this thread that django- > ticketeer is coming along nicely. (For those who don't know, django- > ticketeer is a django front-end for trac installations which was > spawned during the djangocon sprints). It now supports viewing & > editing tickets, adding tickets, and searching tickets, though a lot > of specific aspects of those actions are not yet supported. > > If anyone is interested in contributing, that would be great - > especially people who love front-end work. The project was started > because Trac... doesn't provide the best user experience. Ticketeer > should. This isn't really my business, and possibly not on topic, apart from the fact that Django really ought to be a well-behaved Python citizen, so I thought I'd voice my concern: > The project was started > because Trac... doesn't provide the best user experience. I really cannot understand this as a rationale. If Trac doesn't provide the best user experience, surely the obvious thing would be to fix Trac with some well written patches - it is an open source software after all. Has this been tried? (Genuine question). Have they said "we are not interested in improving user experience" or something? I do genuinely hope I'm wrong, and perfectly willing to be corrected, but to me, this sounds like thinly veiled Not Invented Here syndrome, and I don't think that is good for the Django community. Yes, Trac is not written in Django. But Django isn't perfect, it isn't the best for every job, and I don't want us to antagonise other Python communities by suggesting it is, and by doing our own thing instead of contributing work back to the original project. The latter is much harder in many ways than the former, but I would suggest it is much more profitable in the long run, and a good opportunity to learn from another project, which will surely have significant strengths of its own. Regards, Luke -- I never hated a man enough to give him his diamonds back. (Zsa Zsa Gabor) Luke Plant || http://lukeplant.me.uk/ -- 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: Revisiting proxied SSL headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/24/2011 09:02 AM, Luke Plant wrote: > It is a tricky problem, because I don't know of any perfect solution. My > concern is not only that it is possible to configure incorrectly, it > appears to be virtually impossible to configure correctly, as it appears > to be very hard to get web servers to filter incoming headers, and so > filter a X-Forwarded-Protocol=SSL header that is set by a MITM. Is this actually the case? I know you mention in the ticket that Webfaction's front-end proxy doesn't filter the header they use correctly, but do you have any other evidence that it is "very hard to get web servers to filter incoming headers"? I haven't dug into it deeply, but I've tested with ep.io and I know they do filter their proxy-SSL header correctly, and I've also tested my own nginx reverse-proxy setup, and it enforces the header correctly in all cases, and the configuration to make it do so was trivial (use proxy_set_header X-Forwarded-Protocol in both the HTTP and HTTPS cases). I certainly think the documentation for this feature needs to be extremely clear that setting it is a security risk unless you are absolutely sure that your front-end proxy enforces the header correctly. Perhaps we could also supply some advice on how to check that? Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5+IrAACgkQ8W4rlRKtE2fXFQCfXoI8mW3QWLpNGZb+Tj2UFP/0 MHsAnjUybjgm4YqaJIxj1b2sUEDYqI4T =LPYT -END PGP SIGNATURE- -- 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: Revisiting proxied SSL headers
On 24/09/11 19:34, Carl Meyer wrote: > On 09/24/2011 09:02 AM, Luke Plant wrote: >> It is a tricky problem, because I don't know of any perfect solution. My >> concern is not only that it is possible to configure incorrectly, it >> appears to be virtually impossible to configure correctly, as it appears >> to be very hard to get web servers to filter incoming headers, and so >> filter a X-Forwarded-Protocol=SSL header that is set by a MITM. > > Is this actually the case? I know you mention in the ticket that > Webfaction's front-end proxy doesn't filter the header they use > correctly, but do you have any other evidence that it is "very hard to > get web servers to filter incoming headers"? I haven't dug into it > deeply, but I've tested with ep.io and I know they do filter their > proxy-SSL header correctly, and I've also tested my own nginx > reverse-proxy setup, and it enforces the header correctly in all cases, > and the configuration to make it do so was trivial (use proxy_set_header > X-Forwarded-Protocol in both the HTTP and HTTPS cases). OK, maybe I was generalising from Apache. I do remember searching for a way to get Apache to do it, and there didn't seem to be any obvious solution. I've got a feeling I looked into at least one other popular web server. I may also have been basing my information on how hard it seems to have been to get WebFaction to fix this - 2 years and waiting, and usually are very responsive if there is an easy fix. However, it may just have been overlooked. I'm happy to be proved wrong, of course. Apache is very popular, though, so if its hard in Apache, it could be said to be hard full stop. Regards, Luke -- I never hated a man enough to give him his diamonds back. (Zsa Zsa Gabor) Luke Plant || http://lukeplant.me.uk/ -- 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: confusing things in Trac UI (was: Design decision for #1625...)
On Sun, Sep 25, 2011 at 12:06 AM, Luke Plant wrote: > On 21/09/11 10:40, Stephen Burrows wrote: > >> Just thought it might be worth mentioning in this thread that django- >> ticketeer is coming along nicely. (For those who don't know, django- >> ticketeer is a django front-end for trac installations which was >> spawned during the djangocon sprints). It now supports viewing & >> editing tickets, adding tickets, and searching tickets, though a lot >> of specific aspects of those actions are not yet supported. >> >> If anyone is interested in contributing, that would be great - >> especially people who love front-end work. The project was started >> because Trac... doesn't provide the best user experience. Ticketeer >> should. > > This isn't really my business, and possibly not on topic, apart from the > fact that Django really ought to be a well-behaved Python citizen, so I > thought I'd voice my concern: > >> The project was started >> because Trac... doesn't provide the best user experience. > > I really cannot understand this as a rationale. If Trac doesn't provide > the best user experience, surely the obvious thing would be to fix Trac > with some well written patches - it is an open source software after > all. Has this been tried? (Genuine question). Have they said "we are not > interested in improving user experience" or something? I do genuinely > hope I'm wrong, and perfectly willing to be corrected, but to me, this > sounds like thinly veiled Not Invented Here syndrome, and I don't think > that is good for the Django community. > > Yes, Trac is not written in Django. But Django isn't perfect, it isn't > the best for every job, and I don't want us to antagonise other Python > communities by suggesting it is, and by doing our own thing instead of > contributing work back to the original project. The latter is much > harder in many ways than the former, but I would suggest it is much more > profitable in the long run, and a good opportunity to learn from another > project, which will surely have significant strengths of its own. I completely agree that rebuilding Trac just to have a Django version of Trac isn't a particularly attractive idea to me. If there's some contribution we can make back to Trac, we should certainly do that rather than try and build our own version of Trac that will inevitably have it's own flaws. That said... David Eaves' opening keynote at DjangoCon certainly gave me some food for thought about directions that this sort of project could lead. http://blip.tv/djangocon/keynote-david-eaves-5571777 David spoke about community management, and about how the tools that we use for community management are a key part in coordinating our volunteer user base. In particular, it got me thinking that while Trac may well be a perfectly serviceable tool for managing the internal bug tracking lifecycle, it may *not* be the best public facing tool for interacting with our community. David made the valid point that when someone contributes -- in any way -- having their first experience being "You've posted in the wrong place" or "don't post that here" or "that's a duplicate" isn't very productive -- in fact, it can be counterproductive, as it turns someone who *might* turn into a valuable contributor into someone who has had a negative experience with the project. There may be some space here for a tool that is focussed on this sort of user experience. "Replacing Trac" isn't an interesting goal in itself, but improving the interface to Trac *is* an interesting goal -- and that may mean wrapping Trac in a set of tools that aren't appropriate for inclusion in Trac itself. Yours, Russ Magee %-) -- 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.
