Re: Deprecate FCGI support in Django 1.7

[Ramiro Morales]

On Mon, Jul 15, 2013 at 6:45 PM, Jacob Kaplan-Moss  wrote:
>
> Let's start FCGI (and the others) down the path to deprecation. If there's
> truly a community that finds value in these things -- and frankly I think
> that once they try modern options they'll quickly switch and never look back
> -- then let them maintain the code.

Coincidentally, Juan Luis Boya has just attached a [1]patch to ticket
#20751.

It includes an initial FastCGI testing infrastructure that could be of
help to the maintainers of any project that result of this discussion.

-- 
Ramiro Morales
@ramiromorales

1. 
https://code.djangoproject.com/attachment/ticket/20751/0001-socketumask-argument-for-runfcgi-tests.patch

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django runfcgi umask: what is it meant to do and why?

[Ramiro Morales]

On Mon, Jul 15, 2013 at 3:02 PM, Juan Luis Boya  wrote:
> I've posted a patch for runfcgi here:
>
> https://code.djangoproject.com/ticket/20751
>
> It includes documentation update and unit tests, for anyone interested, if
> any.

Juan Luis,

This is all great work. Thank you very much for it.

There are some new in the fastCGI front:

https://groups.google.com/forum/?hl=en#!topic/django-developers/oGmD8LvLTPg

I will make sure your work isn't wasted and ends in the FastCGI dapter
code whatever
that means (external community maintained project or project under
Django umbrella)

Regards,

-- 
Ramiro Morales
@ramiromorales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Composite fields once again -- irregular status report #2

[Michal Petrucha]

Hello,

I apologize for the lack of updates on the progress of my project in
the past few weeks, there just wasn't much to report, unfortunately.

I spent the past two weeks porting the ForeignKey refactor on top of
master. It took significantly more time to do than I anticipated due
to all the changes in ForeignKey and other ORM internals. Currently
most of the code seems to work, however, I'm in a regression fixing
mode, running the test suite, picking a failing test, fixing and
repeating. I still have 32 failures and 56 errors remaining at the
moment, which is significantly less than the 200 failures and 1100
errors I started at, but still quite a lot.

The work is slow, tedious and quite tiring, each regression takes at
least a couple-three hours to figure out (often even longer) and
doesn't decrease the number of remaining errors all that much.

I'm one week behind my schedule right now, unfortunately, it seems
that this lag will increase further. Well, I was too optimistic in my
proposal...

The good news is that the changes I'm required to make at this stage
will make support for composite fields even easier to implement than I
anticipated.

Feel free to check out the code on Github [1].

Michal


[1] https://github.com/konk/django/tree/soc2013/foreignkey-refactor


signature.asc
Description: Digital signature

Re: Deprecate FCGI support in Django 1.7

[Jacob Kaplan-Moss]

On Mon, Jul 15, 2013 at 4:31 PM, Florian Apolloner wrote:

> Also, if we move it outside of django-core we can send a good signal that
> FCGI in Django is basically "Use at your own risk" (which it is already if
> you ask me).
>

This, for me, is the key: anything that's not a WSGI container is basically
the wrong way to serve Django. Full stop. By continuing to include these
other weird protocols we're implying that they're fully supported when
they're actually totally not. Back in the day, we needed FCGI support
because the options for hosting Python stuff was super limited. Today,
there are a ton of options, even in the ultra-low-cost category.

Let's start FCGI (and the others) down the path to deprecation. If there's
truly a community that finds value in these things -- and frankly I think
that once they try modern options they'll quickly switch and never look
back -- then let them maintain the code.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Jacob Kaplan-Moss]

On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis  wrote:

> Is it considered gauche to revive old topics such as this?


It's not, but my opinion hasn't changed -- I'm still -1, and so's Adrian.
So unless you've got something really convincing, an argument that hasn't
been presented yet that is totally going to change both of our minds --
it's probably not worth your time.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Florian Apolloner]

On Monday, July 15, 2013 9:55:51 PM UTC+2, Aymeric Augustin wrote:
>
> - Django's core developers don't use FCGI — at least, I don't know any 
> active core dev who does. 
>

I do, but with a patched flup and a patched suexec and what else, so I am 
hardly a typical usecase; and I am in the process of moving the systems to 
a sane setup.
 

> That makes FCGI a dead end. At some point we'll have to pull the plug. 
> Right now seems early. 
>

The plug is pulled when it's removed from Django, deprecating doesn't mean 
right now. Also, if we move it outside of django-core we can send a good 
signal that FCGI in Django is basically "Use at your own risk" (which it is 
already if you ask me).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Florian Apolloner]

On Monday, July 15, 2013 6:20:45 PM UTC+2, Some Developer wrote:
>
> What about SCGI and AJP support? Is that going? 
>
Yes, it's either all or nothing.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Daniel Ellis]

Is it considered gauche to revive old topics such as this?  After having 
some difficulty debugging why an if statement was throwing a strange error, 
I realized it was because they didn't support multi-line statements. 
 Here's what I was trying:

{% if request.xxx.family.get_selected.get_age < program
  or request.xxx.family.get_selected.get_age > program.max_age %}

Fairly simple stuff.  Keeping this on a single line gets unwieldy, yet the 
logic isn't nearly convoluted enough that it should be de-facto moved 
elsewhere.  It seems a bit more pythonic to split to multiple lines.

On Monday, February 27, 2012 9:37:56 AM UTC-5, Ned Batchelder wrote:
>
> On 2/26/2012 12:12 AM, Yo-Yo Ma wrote:
> > After Ned's message, I'm -0, because while I'm not fond of multi-line
> > tags, I cannot offer a good alternative when it comes to multi-line
> > "with" tags.
> >
> > On Feb 25, 6:48 pm, Ned Batchelder  wrote:
> >> On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:>  I'm -1 on this for s specific 
> reason; If you need multiple lines for a
> >>> tag, you're doing it wrong.
> >> import this
> >> This would be far more helpful feedback if you would take the examples
> >> of too-long tags presented in this thread, and show the "right" way to
> >> do it.
> >>
> >> --Ned.
> While I'm glad to see people being open to changing their minds, it 
> worries me that none of the "one-line tag" aesthetes have spoken up to 
> explain how they would deal with the unwieldy constructions that started 
> this thread.  In fact, so far two people have changed their minds when 
> actually grappling to come up with an answer.
>
> What is the right way to do this:
>
> {% trans with
>   varname=myobject.proprety1
>   someothervar=myobject.some.other_property
>   yetanothervar=myotherobject.with_a_painfully_long_method_name
>   "Even with line-wrap, it's a pain to read on a single line."
> %}
>
> or
>
> {% blocktrans with 
> originator=entry.originator|get_really_full_name:"mailto" 
> link=entry.get_metadata.link 
> task_id=entry.task.idprocess_name=entry.task.process_class|contenttype_name %}
>
> Powers-that-be declaring, "X is ugly and won't happen" is inevitable, 
> but we should be able to extend the answer with "and Y is the way to do 
> it better?"
>
> --Ned.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django runfcgi umask: what is it meant to do and why?

[Juan Luis Boya]

I've posted a patch for runfcgi here:

https://code.djangoproject.com/ticket/20751

It includes documentation update and unit tests, for anyone interested, if 
any.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Some Developer]

On 15/07/2013 13:37, Florian Apolloner wrote:

On Monday, July 15, 2013 9:38:33 AM UTC+2, Some Developer wrote:

This would be a mistake in my opinion.


Based on what? Django would still support FCGI via flup like it does
now, we'd just get rid of the management commands you usually can't use
on shared hosting either way…


OK. Your initial post was somewhat confusing in that case.


I'd like to get rid of everything FCGI-specific in Django sooner or later 
(rather sooner).


The question is why? There is very little FastCGI boilerplate in Django 
as it is and what is there hasn't been touched for a number of years 
(the runfcgi management command file hasn't been touched for 6 years).


Why not just remove the documentation for FastCGI, SCGI and AJP and make 
it clear that WSGI is the only supported option for deploying Django 
applications but keep the legacy code available for those who already 
use it.


Developers then don't need to worry about breaking it since it is no 
longer supported and those that do use FastCGI, SCGI and AJP can submit 
patches to fix it if it ever does get broken. This also includes 
submitting patches to flup if it is still maintained or taking it over 
if it is not.


This way everyone wins.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[gilberto dos santos alves]

remember that on "shared hosts" we do not have option to use, explicity
http ports, like examples from [1]. we do not have root access, nor
http.conf access for apache2/root configs.

when we hare dedicated server it is easy run app with django.

on shared host, all config for running django fcgi is made using with user
ssh terminal, and with sftp/ftp (example filezilla), .htaccess files and
cpanel.

for install uwsgi we need c compiler, that we do not have on shared hosts.

It is more easy and less expensive for "first-time companies using web
apps" use shared hosts and only solution that i find is using fcgi.

if necessary additional work todo (installs, .htaccess, etc) it is not the
problem


[1] http://flask.pocoo.org/docs/deploying/fastcgi/?highlight=fcgi


2013/7/15 Some Developer 

> On 15/07/13 16:10, Florian Apolloner wrote:
>
>> On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote:
>>
>> If you're suggesting to move the FastCGI code into a separate app: +1
>>
>>
>> I'd have just dropped it, but yes we can move it out; although someone
>> else will have to step up to continue maintaining it (if there is a need
>> to maintain it).
>>
>> Florian
>>
>
> What about SCGI and AJP support? Is that going?
>
> Seems silly to drop FastCGI which is probably the most popular of three
> and leave the other two intact. If you're going to drop something drop all
> three.
>
> At least then it is clear to users that WSGI is the only supported option
> in Django.
>
> Third parties can then maintain FastCGI, SCGI and AJP support (which I
> believe all come from flup anayway).
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> django-developers+unsubscribe@**googlegroups.com
> .
> To post to this group, send email to 
> django-developers@**googlegroups.com
> .
> Visit this group at 
> http://groups.google.com/**group/django-developers
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>


-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Some Developer]

On 15/07/13 16:10, Florian Apolloner wrote:

On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote:

If you're suggesting to move the FastCGI code into a separate app: +1


I'd have just dropped it, but yes we can move it out; although someone
else will have to step up to continue maintaining it (if there is a need
to maintain it).

Florian


What about SCGI and AJP support? Is that going?

Seems silly to drop FastCGI which is probably the most popular of three 
and leave the other two intact. If you're going to drop something drop 
all three.


At least then it is clear to users that WSGI is the only supported 
option in Django.


Third parties can then maintain FastCGI, SCGI and AJP support (which I 
believe all come from flup anayway).


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #20739 - Making LiveServerTestCase not depend on staticfiles?

[Ramiro Morales]

Hi Jannis, Thanks for your reply,

On Sun, Jul 14, 2013 at 10:16 AM, Jannis Leidel  wrote:
>
> I'm pretty sure we don't want to increase the code that deals with
> serving files. We've repeatedly improved the documentation about
> helping users to configure their web server to serve the files instead
> of adding an official file serving WSGI middleware like you propose
> here. Especially since we already provide a view in
> django.views.static to serve files I think we need to clarify what the
> purpose of the FSFilesHandler would be. If there is little good reason
> (e.g. only supporting LiveServerTestCase) then we **shouldn't** make
> the FSFilesHandler a new core component but just a implementation
> detail.

It would support it and the staticfiles handler but I agree with you on
that we should not be shipping something like FSFilesHandler or at least
should move it near where it's used and/or marking/documenting it as
internal.

>
>> Another change introduced is duplicating (simplifying it slightly)
>> django.contrib.staticfiles.views.serve() view functionality.
>
> Where was that duplicated specifically? Couldn't find it in the pull request.

Ah yes, sorry for not making the PR  more granular commit-wise. This is
the staticfiles serve() view:

https://github.com/django/django/blob/master/django/contrib/staticfiles/views.py#L20

and this is the new, albeit simplified, duplicate copy:

https://github.com/django/django/pull/1354/files#L3R1072

>
>> The last stumbling block we need to remove is use of staticfiles'
>> finders infrastructure, for which I don't have any solution for now.
>
> Maybe the LiveServerTestCase should simply have a generic file serving
> feature, basically just using the core static view to serve
> STATIC_ROOT under STATIC_URL.
>
> Users that want to continue using staticfiles we could ask to call
> collectstatic in a setUpClass method in their LiveServerTestCase
> subclasses. Or just ask them to run it before running the tests.
>
> [...] I think decoupling the file serving slightly from how the files
> got to the place they are served from, is a good first step. The
> common denominator between the core ability to serve files and
> staticfiles is the reliance on conventions like STATIC_ROOT and
> STATIC_URL. If we can backscale LiveServerTestCase to only do the core
> ability out of the box and document the way to do it the staticfiles
> way, then I think we're on the right track.

I will be working further on the PR keeping all this design advice in
mind.

Thanks again,

>
> Jannis
>

-- 
Ramiro Morales
@ramiromorales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Florian Apolloner]

On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote:
>
> If you're suggesting to move the FastCGI code into a separate app: +1 
>

I'd have just dropped it, but yes we can move it out; although someone else 
will have to step up to continue maintaining it (if there is a need to 
maintain it).

Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Jannis Leidel]

On 14.07.2013, at 21:17, Florian Apolloner  wrote:

> Hi,
> 
> I'd like to get rid of everything FCGI-specific in Django sooner or later 
> (rather sooner). Flup isn't maintained since a long time and there is no 
> ticket tracker to report stuff. Graham pointed out that if someone wants to 
> use FCGI they can use 
> http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socket which 
> doesn't even require flup, which sounds like a good compromise to me. I'd 
> need some help for the docs from some uWSGI users, since I have no idea about 
> it ;)
> 
> Thoughts, objections?

If you're suggesting to move the FastCGI code into a separate app: +1

In other words, I don't think we can remove it from Django and not provide a 
migration path for FastCGI users. It's simple enough to move the runfcgi 
management command and the flup based handler into a separate app without 
having to risk changes in behavior.

Jannis

PS: I've just registered django-fcgi on PyPI in case you want to release it 
under that name.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Some Developer]

On 15/07/13 13:13, mjl Martin J. Laubach wrote:

   Is there actually a problem with flup? Not being maintained doesn't
mean it's totally broken and it obviously works just fine for a lot of
folks?

 mjl


I use it myself and haven't had any issues with it either I was just 
responding to one of the previous posters who stated that because flup 
was unmaintained it was a good reason to deprecate FastCGI in Django. He 
did make a good point about there being no bug tracker but as I said if 
it became a critical issue then a fork is always on the cards.


I'd be interested if any contact has been made with the author of flup 
to see whether he has dropped the project or whether he just doesn't get 
any bug reports warranting a new release.


Personally I haven't had any issues with flup at all. In fact for me 
Django with flup + nginx + daemontools works wonderfully for production 
sites. Perhaps not as fast as uWSGI but it is solid enough.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Christopher Medrela]

Progress: I've implemented manager checks.

The schedule for the next 4 weeks is:

1. Manager checks (ref 4.1.7)(done)(0.5 week).
2. Entry point registering (ref 4.1.5) & rewriting mechanism of triggering
   checking framework (ref 4.1.9)(1.5 week).
3. Moving custom User model checks (ref 4.1.6)(0.5 week).
4. Rewriting AdminModel checks and tests (ref 4.1.8)(1 week).
5. Polishing doc (ref 4.1.10)(0.5 week).

(ref 4.1.x are references to my original proposal [1])

[1] https://gist.github.com/chrismedrela/82cbda8d2a78a280a129)

Let's talk about public API to register your own validation stuff. There 
will
be `register(callable)` function in `django.core.checks`. It will return
nothing. The callables will be stored in a global variable. They should obey
the same contract as `check` methods: they allow for `**kwargs` and return
list of errors and warnings. All registered callables will be called during
checking phase (i. e. when you type `manage.py validate` or before running
server).

This API allows us to register, among other things, app-specific checks. But
it's not necessary to write an app in order to do some checks.

`register` function will have two optional parameters: `run_in_production`
(default: False) and `run_in_development` (default: True) that let you 
specify
when the callable should be called. Most checks should be performed only in
development environment (which is equivalent to DEBUG==True). Security 
checks
makes sense only in production environment (<==> DEBUG==False).

I would be happy if I could hear your opinion!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Florian Apolloner]

On Monday, July 15, 2013 7:07:08 AM UTC+2, Russell Keith-Magee wrote:
>
> I'm not arguing that FastCGI is a good option, just that it's prevalent. 
> And if we're going to stop supporting it, we need to be aware of who we're 
> cutting off.
>

We won't cut anything off (maybe aside from the runfcgi command). 
Supporting FCGI should be as easy as shown in the flask docs: 
http://flask.pocoo.org/docs/deploying/fastcgi/ -- This means that even if 
we remove everything FCGI specific from Django this doesn't prevent people 
from using FCGI+Django, it just means they have a bit more work to do 
(although if you look at the flask docs, it's really just a .fcgi file).

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Spam on ticket #542

[Florian Apolloner]

On Monday, July 15, 2013 3:20:16 AM UTC+2, Ramiro Morales wrote:
>
> Would it be worth look at the web server log to see if these comments 
> were effectively created by HTTP POST requests at all? 
>

That's what I did to figure out the ip (which I blocked via iptables before 
Aymeric played with the apache config). 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.