Re: Code styling around URL in 404 pages shown with DEBUG = True

[Aymeric Augustin]

Hello James,

This sounds reasonable. I would avoid using “root directory” to describe an URL 
because there isn’t usually a mapping between directories and URLs in Django 
projects.

-- 
Aymeric.



> On 26 nov. 2015, at 23:44, James Lu  wrote:
> 
> When you get a 404 with DEBUG = True the URL shown (look at the arrow in 
> image below) isn't in a code box. Additionaly, it'd be helpful if the URL is 
> root it shows (root directory)
>  or something similar. 
> 
> ​
> 
> Asking for the OK before submitting as a feature request, thanks.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CANQHGB3xNNdh4Gip-CGA9wjqtTZNyiz1knVvyiWxCDrfA%2Bdszg%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2BCC88EC-E98E-4D0B-913D-501A7F98DA75%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Code styling around URL in 404 pages shown with DEBUG = True

[James Lu]

When you get a 404 with DEBUG = True the URL shown (look at the arrow in
image below) isn't in a code box. Additionaly, it'd be helpful if the URL
is root it shows (root directory)
 or something similar.

​

Asking for the OK before submitting as a feature request, thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANQHGB3xNNdh4Gip-CGA9wjqtTZNyiz1knVvyiWxCDrfA%2Bdszg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: annoyance with Python 3.2 support in Django 1.8

[Donald Stufft]

> On Nov 26, 2015, at 9:50 AM, Tim Graham  wrote:
> 
> The thing that makes me a little uncomfortable is promoting the use of 
> possibly insecure Python 3.2 well after it's end-of-life. I guess there might 
> be some Linux distributions that will backport security fixes to their own 
> versions of Python 3.2, but it seems that Ubuntu 12.04's version of Python 
> 3.2 didn't incorporate the security fix which caused breakage.


FTR the next major version of pip does not support Python 3.2.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/247186BB-8325-4418-9046-AAA5E6C9711D%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: annoyance with Python 3.2 support in Django 1.8

[Tim Graham]

The thing that makes me a little uncomfortable is promoting the use of 
possibly insecure Python 3.2 well after it's end-of-life. I guess there 
might be some Linux distributions that will backport security fixes to 
their own versions of Python 3.2, but it seems that Ubuntu 12.04's version 
of Python 3.2 didn't incorporate the security fix which caused breakage.

Is there anyone reading this planning a long-term deployment of Python 3.2? 
If so, how long?

Yes, we could mark the tests as expected failure if needed.

On Thursday, November 26, 2015 at 9:36:32 AM UTC-5, Aymeric Augustin wrote:
>
> Hello Tim,
>
> Did you consider marking affected tests as expected failures on Python 
> 3.2.6?
>
> I've done that on one of my projects which faced this exact issue (or a 
> closely related one):
>
> https://github.com/aaugustin/myks-gallery/blob/master/gallery/test_admin.py#L199-L205
>
> Best regards,
>
> -- 
> Aymeric.
>
> 2015-11-26 1:36 GMT+01:00 Tim Graham :
>
>> Django 1.8 is the last version to support Python 3.2. Python 3.2 is 
>> scheduled to be end of life at February 2016 [1] while Django 1.8 is 
>> scheduled to be supported until April 2018. The latest security release for 
>> the 3.2 series, Python 3.2.6 contained a regression that causes 30 admin 
>> test failures in the Django test suite related to parsing of httponly 
>> cookies. I'm not sure if this problem is limited to the test client or if 
>> it has the potential to cause problems in a web server context (if anyone 
>> is using Python 3.2.6, I'd be interested to know). I submitted a patch to 
>> Python to correct the issue [2], but it appears unlikely that the patch 
>> will be applied along with a new release (no response from Python 3.2 
>> release manager in 1 year).
>>
>> Due to the test failures, we cannot run the Django test suite with Python 
>> 3.2 on the Ubuntu 14.04 CI machines which use the deadsnakes PPA [3] to 
>> install the latest version of Python (3.2.6). Therefore the tests are 
>> limited to running on our one remaining Ubuntu 12.04 CI machine which 
>> includes Python 3.2.3 (deadsnakes doesn't bundle versions of Python that 
>> would override the one included by the distribution). Support for Ubuntu 
>> 12.04 ends April 2017, so we shouldn't keep that machine longer than that.
>>
>> Options:
>> 1. Drop Python 3.2 support for Django 1.8 sometime before Django 1.8 EOL
>> 2. Keep Python 3.2 support until Django 1.8 EOL:
>>   a. Don't worry about CI support and rely on local testing of security 
>> fixes (we had the same situation with Django 1.4 and Python 2.5)
>>   b. Install the latest non-broken Python 3.2 release (3.2.5) "manually" 
>> (without using deadsnakes) on the newer CI servers
>> 3. Your idea
>>
>> Thanks for your feedback!
>>
>> [1] https://www.python.org/dev/peps/pep-0392/
>> [2] https://bugs.python.org/issue22758
>> [3] https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/34dd15c4-dba5-46fe-9ac0-6d5a426db2df%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Aymeric.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/93c64bac-07e6-4ed4-ac9e-f54dc5f927ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: annoyance with Python 3.2 support in Django 1.8

[Aymeric Augustin]

Hello Tim,

Did you consider marking affected tests as expected failures on Python
3.2.6?

I've done that on one of my projects which faced this exact issue (or a
closely related one):
https://github.com/aaugustin/myks-gallery/blob/master/gallery/test_admin.py#L199-L205

Best regards,

-- 
Aymeric.

2015-11-26 1:36 GMT+01:00 Tim Graham :

> Django 1.8 is the last version to support Python 3.2. Python 3.2 is
> scheduled to be end of life at February 2016 [1] while Django 1.8 is
> scheduled to be supported until April 2018. The latest security release for
> the 3.2 series, Python 3.2.6 contained a regression that causes 30 admin
> test failures in the Django test suite related to parsing of httponly
> cookies. I'm not sure if this problem is limited to the test client or if
> it has the potential to cause problems in a web server context (if anyone
> is using Python 3.2.6, I'd be interested to know). I submitted a patch to
> Python to correct the issue [2], but it appears unlikely that the patch
> will be applied along with a new release (no response from Python 3.2
> release manager in 1 year).
>
> Due to the test failures, we cannot run the Django test suite with Python
> 3.2 on the Ubuntu 14.04 CI machines which use the deadsnakes PPA [3] to
> install the latest version of Python (3.2.6). Therefore the tests are
> limited to running on our one remaining Ubuntu 12.04 CI machine which
> includes Python 3.2.3 (deadsnakes doesn't bundle versions of Python that
> would override the one included by the distribution). Support for Ubuntu
> 12.04 ends April 2017, so we shouldn't keep that machine longer than that.
>
> Options:
> 1. Drop Python 3.2 support for Django 1.8 sometime before Django 1.8 EOL
> 2. Keep Python 3.2 support until Django 1.8 EOL:
>   a. Don't worry about CI support and rely on local testing of security
> fixes (we had the same situation with Django 1.4 and Python 2.5)
>   b. Install the latest non-broken Python 3.2 release (3.2.5) "manually"
> (without using deadsnakes) on the newer CI servers
> 3. Your idea
>
> Thanks for your feedback!
>
> [1] https://www.python.org/dev/peps/pep-0392/
> [2] https://bugs.python.org/issue22758
> [3] https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/34dd15c4-dba5-46fe-9ac0-6d5a426db2df%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mWHSKZfjpo-5BH40-kZVF%2BXq-TYo2cCeLPpiegbmbJN8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: annoyance with Python 3.2 support in Django 1.8

[Raphael Michel]

Hi,

Am Wed, 25 Nov 2015 16:36:52 -0800 (PST)
schrieb Tim Graham :
> b. Install the latest non-broken Python 3.2 release (3.2.5)
> "manually" (without using deadsnakes) on the newer CI servers

While it would only really hurt the people in charge with the bugfix
releases, as Django 1.8 will be around for another 2.5 years, I think
dropping CI is not a good idea, considering that is comparatively easy
to compile specific python versions by oneself.

However, we should definitely document somewhere that there are
possbile unknown problems with 3.2.6 and the django admin.

Cheers
Raphael

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20151126152618.2f4dba63%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpBiht4aGxUy.pgp
Description: Digitale Signatur von OpenPGP

Re: Allow impossible model validation (mainly admin and generic forms)

[Vlastimil Zíma]

General flow for forms should develop to this:

form = MyModelForm(data)
if form.is_valid():
try:
form.save()
except ValidationError, error:
form.add_error(None, error)
else:
return redirect('success')
return render_failure(form)

While handling such case in custom view is simple. But handling this case, 
when using views from Django is completely different level. In generic 
views it is still possible to override `form_valid` to handle 
IntegrityError or other required exception, but it is not possible to do so 
in ModelAdmin 'add_view' and 'change_view'. There it requires rebuilding 
the whole context which is duplication of about 30 lines from '
changeform_view'.

Dne čtvrtek 26. listopadu 2015 13:30:50 UTC+1 Tom Christie napsal(a):
>
> > Append form's non_field_errors with message like
>
> Given that the IntegrityError doesn't occur until the point of .save(), 
> it's not obvious how that'd work in terms of the Forms API.
> You're absolutely correct that there's a class of constraints that can 
> fail here, but it's not evident to me that dealing with these explicitly 
> when required (in practice, fairly rare) isn't a better tack.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c7bf261c-bcf6-4903-bc82-49586bc23875%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: annoyance with Python 3.2 support in Django 1.8

[Aymeric Augustin]

2015-11-26 5:22 GMT+01:00 Asif Saifuddin :

> Python 3.2 should be removed as if any one use py3 should use 3.3+ or
> better the latest stable.
>

Hi Asif,

Your email sounds like the answer is obvious. It doesn't show that you
thought about the use cases, especially those you don't have yourself and
may be less familiar with. As such it's hard to take it at face value.

More generally, I've noticed that your contributions, either on this
mailing list or on the bug tracker, tend to be very terse, not to bring new
information, and not to be open for further debate. You'll be more
convincing if you show that you took the time to understand the problem at
hand and explain why you suggest a trade-off. When a question is being
debated, there are usually at least two sides and any choice results from a
trade-off e.g. X matters, but Y matters more.

Thanks,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mVENF9ht%3DwoEZccYQyBCOwAsTKKfUm1%3DWVeV_PcZONdMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow impossible model validation (mainly admin and generic forms)

[Tom Christie]

> Append form's non_field_errors with message like

Given that the IntegrityError doesn't occur until the point of .save(), 
it's not obvious how that'd work in terms of the Forms API.
You're absolutely correct that there's a class of constraints that can fail 
here, but it's not evident to me that dealing with these explicitly when 
required (in practice, fairly rare) isn't a better tack.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/96d28748-5c24-4448-a83a-f0ac51a30946%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make template caching a feature of the Django template engine

[Jaap Roes]

Yes, more or less. Although it's not strictly required to deprecate the 
cached template loader.

However if we can deprecate the cached template loader I'd also like to 
deprecate the weird way of passing arguments to template 
loaders 
https://github.com/django/django/blob/master/django/template/engine.py#L116. 
The issue with that is that the locmem loader also uses it.

It would also be interesting to look at the possibility to set a cache 
backend for the template cache, i.e. don't use process memory but memcached 
instead.

On Tuesday, November 24, 2015 at 8:32:49 PM UTC+1, Marc Tamlyn wrote:
>
> So. If I understand correctly, this would deprecate the existing cached 
> template loader, replace it with a more powerful, debug ready version (on 
> by default?). Assuming this is what you mean, I wholeheartedly support 
> this. There's no reason not to be performant by default.
>
> Marc
> On 23 Nov 2015 2:16 pm, "Jaap Roes"  
> wrote:
>
>> It’s considered a good practice to enable template caching in Django. It 
>> saves on the overhead of loading and parsing templates and turning them 
>> into template objects, which can give a nice performance boost when 
>> repeatedly rendering the same templates.
>>
>> Currently it’s possible to enable template caching by using the cached 
>> loader. To do so you’ll need to add the loaders option to the engine 
>> settings and set it to a nesting of lists/tuples (I’ll wager no one can get 
>> this correct on the first try without first consulting the docs). This 
>> makes enabling template caching needlessly hard, and the discoverability of 
>> this feature lower than necessary. To this day I run into developers who 
>> have worked with Django for years but are unaware of the cached loader.
>>
>> One of the downsides of enabling the cached loader is that it will cache 
>> templates until the server is reloaded. This makes it ill suited for 
>> development. I have, on many occasions, seen developers (including myself) 
>> forget to turn off template caching in their local settings, resulting in 
>> lost time trying to figure out why their changes are not showing.
>>
>> I think Django can, and should do better. The bare minimum is to make 
>> template caching a simple toggle option that can be passed to the engine (
>> https://code.djangoproject.com/ticket/25788 / 
>> https://github.com/jaap3/django/commit/21e9d3aa0eb0a9d2728f8a35318d49d528f3a60f
>>  
>> (an admittedly naive patch)). This way cache_templates could simply mirror 
>> DEBUG and (new) projects can have a sane template caching configuration by 
>> default.
>>
>> It would also be useful to have caching enabled in development so the 
>> template loading behaviour is (mostly) the same in development as it is in 
>> production.
>>
>> One reason for this is that custom template tags need to be thread safe (
>> https://docs.djangoproject.com/en/1.8/howto/custom-template-tags/#thread-safety-considerations).
>>  
>> Because cached templates always reuse the nodes it’s easier to notice when 
>> a template tag misbehaves.
>>
>> Another reason is that the performance of template rendering will be 
>> roughly the same development as in production, which can make a great 
>> difference if you’re working with complex templates and/or custom tags that 
>> perform expensive operations in their __init__.
>>
>> Off course, having caching on in development is impractical if templates 
>> stay cached forever. So some sort of template invalidation and reloading 
>> system needs to be added. It’s actually fairly easy to add this to the 
>> cached loader https://code.djangoproject.com/ticket/25791 / 
>> https://github.com/jaap3/django/commit/20e1caa9f923d82ce60dff155304de5289242186
>>  
>> (an earlier/alternative implementation that moves caching to the engine can 
>> be found here: 
>> https://github.com/prestontimmons/django/commit/4683300c60033ba0db472c81244f01ff932c6fb3
>> ).
>>
>> With caching and auto reloading as a core feature of Django’s engine it 
>> will be (somewhat) on par with the alternative Jinja2 engine shipped by 
>> Django. Jinja2’s Engine lets you configure an Environment (
>> http://jinja.pocoo.org/docs/dev/api/#jinja2.Environment) using the 
>> engine's options. This includes setting a bytecode_cache and enabling 
>> auto_reload (this last option mirrors DEBUG by default in Django).
>>
>> So in short, I propose making template caching a true feature of Django’s 
>> template engine. Which can be configured in a way similarl to the Jinja2 
>> engine (and could be on by default for new projects):
>>
>> TEMPLATES = [{
>> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
>> 'DIRS': [os.path.join(BASE_DIR, 'templates')],
>> 'APP_DIRS': True
>> 'OPTIONS': {
>> 'cache_templates': True, 
>> 'auto_reload': DEBUG  // this could be the default set by the 
>> engine
>> }
>> }]
>>
>> -- 
>> You received this message because you are subscribed to the 

Re: Allow impossible model validation (mainly admin and generic forms)

[Vlastimil Zíma]

Hi guys,

to answer Tim's questions:

> Would Django itself ever raise ValidationError in Model.save()?

That can be possible. Currently I have no clear opinion of where 
IntegrityError and other errors should be changed to ValidationError.

> I wonder how you propose converting something like an IntegrityError from 
the database into an "friendly" exception for the user?

The message doesn't have to be specific. Append form's non_field_errors 
with message like "An unexpected error occured while saving the data. 
Please try again." is in my opinion way better than server error caused by 
unhandled exception. I'm not in favor of re based heuristics to get details 
from integrity error message as noted by Aron.

Vlastik

Dne čtvrtek 26. listopadu 2015 7:34:32 UTC+1 Aron Podrigal napsal(a):
>
> I'm also in favor of some solution here. I used to raise a ValidationError 
> with either a particular field if I was able to extract the particular 
> error via regex matches, or as non_field_errors. That was my best I had 
> instead of resulting in a 5xx. In most cases for example a unique race 
> condition, when the user will resubmit the form it will have the detailed 
> validation errors or pass.
> On Nov 25, 2015 1:57 PM, "Tim Graham"  
> wrote:
>
>> Would Django itself ever raise ValidationError in Model.save()?
>>
>> I wonder how you propose converting something like an IntegrityError from 
>> the database into an "friendly" exception for the user?
>>
>> On Wednesday, November 25, 2015 at 9:23:05 AM UTC-5, Vlastimil Zíma wrote:
>>>
>>> Django assumes that all input data in forms can be validated by 
>>> `Form.is_valid()` which in some cases is not true. Database contraints, 
>>> e.g. unique, can fail even though they are checked. An application may 
>>> require communication with other servers while processing data which can 
>>> lead to errors. But these conditions are not expected by regular Django 
>>> form flow and an attempt to handle these cases results in large overriding 
>>> of default implementation.
>>>
>>>
>>> This topic was previously discussed here 
>>> https://groups.google.com/d/topic/django-developers/rzjpP0byNQo/discussion, 
>>> but discussion was mainly based on race condition in unique check. I'd like 
>>> to reopen the topic because there are other possibilities which may cause 
>>> the possibility of failure after form validation to become real, especially 
>>> if network connection is involved.
>>>
>>>
>>> I suggest Django should provide mechanism which allow handling the 
>>> unexpected failures after form validation, e.g. expect `ValidationError` to 
>>> be raised by `ModelAdmin.save_model`.
>>>
>>>
>>> I started this discussion as a result of wontfix from 
>>> https://code.djangoproject.com/ticket/25777.
>>>
>>>
>>> Vlastik
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1db10ddc-eae6-4f17-a596-b8ce1aa8ef1f%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c80d79ed-518e-44da-903a-6f5ae166e69d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.