Design Decision: GFK Reverse Lookups

[Carlton Gibson]

Hi All.

https://github.com/django/django/pull/9748 adds the ability to perform 
simple queries on a generic foreign key: 

TaggedItem.objects.filter(content_object=object_instance)

You still can't do anything more complex, such as:

TaggedItem.objects.get(content_object__name='Diamond')

This is a long standing 
Someday/Maybe: https://code.djangoproject.com/ticket/3006



The patch seems more or less OK to me but I'm not sure if we shouldn't 
*instead* guide users firmly towards defining a GenericRelation. 

GenericRelation provides for the more powerful querying, and, this way, 
provides the one correct way™ to do things. 

I'm wondering what the correct view should be: whether we take this patch 
or close the issue as wontfix and solely recommend GenericRelation. 



Thanks for your input. 

Kind Regards,

Carlton

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c81e6d2d-7254-4ad5-b8dd-c8c05726f55c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Adam Johnson]

Oh yeah, duh, my bad :)

On 9 April 2018 at 23:35, Collin Anderson  wrote:

> I'm thinking something like #!/usr/bin/env {{ os.path.basename(sys.executable)
> }} when running startproject. (Though on windows I that would
> be #!/usr/bin/env python.exe - not sure if that would work or not)
>
> On Mon, Apr 9, 2018 at 3:58 PM, Adam Johnson  wrote:
>
>> (Or would it work to use os.path.basename(sys.executable) ?)
>>
>>
>> The shebang is interpreted by the OS so this is before python even starts
>> :)
>>
>> On 9 April 2018 at 20:53, Collin Anderson  wrote:
>>
>>> I personally just edit my manage.py to change it from python to python3.
>>> Maybe we could just document that?
>>>
>>> (Or would it work to use os.path.basename(sys.executable) ?)
>>>
>>> On Sun, Apr 8, 2018 at 11:02 AM, Tom Forbes  wrote:
>>>
 It may be an obstacle but I believe it’s better than having them nuke
 their base systems by accident by installing a package that conflicts with
 their base system. This isn’t such a huge issue on MacOS but on Linux it is
 and I’ve seen it happen a few times. Not to mention the issue of multiple
 conflicting dependencies across projects - all in all it’s really not a
 recommended and we should not look to make it easier IMO.

 People have different setups and whatever works, works, but things like
 pipenv are maturing rapidly and solve the convenience issue you
 describe. I personally use virtualenvwrapper which is really simple to
 set up and displays the current virtual environment in the prompt, and
 makes it really easy to switch between them/create new ones.

 Tom



 On 8 April 2018 at 15:00:46, Bobby Mozumder (bmozum...@gmail.com)
 wrote:

 I never really liked the idea of using VirtualEnv or HomeBrew over the
 default installation in Mac OS.  (FreeBSD has the same naming issues).

 Having beginners use VirtualEnv or HomeBrew always struck me as a huge
 obstacle to getting a beginners Django developer's environment operational,
 as well as being a huge pain-in-the-ass of always setting VirtualEnvs for
 each shell.  So, I personally don’t use them anymore, and just use the base
 system now.

 I wish there was a process of running Django out-of-the-box from a
 default Mac OS install.

 -bobby

 On Apr 8, 2018, at 8:27 AM, Tom Forbes  wrote:

 This only seems to be an issue when you are using the base system
 interpreter to run manage.py. installing Django and other dependencies
 there is not recommended for a variety of reasons, and this isn't a problem
 when using a virtualenv, it doesn't seem like there is much to fix IMO.


 On Sun, 8 Apr 2018, 08:19 Bobby Mozumder,  wrote:

> Is it OK to reopen that ticket?
>
> The problem is that python2 and python3 need to coexist in most
> systems, and you can’t just rename python3 to python.
>
> -bobby
>
> On Apr 6, 2018, at 8:30 PM, Tim Graham  wrote:
>
> It was tried in https://code.djangoproject.com/ticket/27878 but it
> caused problems, particularly on Windows.
>
> On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote:
>>
>> I think you're right and PEP394 is the relevant text:
>> https://www.python.org/dev/peps/pep-0394/
>>
>> TL;DR
>>
>> For now, *python* should refer to python2 and *python3* should be
>> used to refer to python 3.
>>
>> On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote:
>>>
>>> The header of manage.py has: #!/usr/bin/env python
>>>
>>> Shoudn’t it be: #!/usr/bin/env python3
>>>
>>> Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments
>>> have Python 3.5+ as “python3". (I’m not sure about Linux or other
>>> environments).
>>>
>>> Is that a bug I need to file?
>>>
>>> -bobby
>>>
>>
> --
> 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@googlegro
> ups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.co
> m/d/msgid/django-developers/7cdf48bb-ab0b-449d-8f33-a4c6d777
> 7369%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)" g

Re: Shouldn't manage.py call python3 instead of python?

[Tim Allen]

Since `django-admin startproject my_project` is created on the fly from 
templates, couldn't we dynamically create the `manage.py` executable based 
on some system introspection and an agreed upon priority?

Regards,

Tim

On Tuesday, April 10, 2018 at 4:28:12 AM UTC-4, Adam Johnson wrote:
>
> Oh yeah, duh, my bad :)
>
> On 9 April 2018 at 23:35, Collin Anderson  > wrote:
>
>> I'm thinking something like #!/usr/bin/env 
>> {{ os.path.basename(sys.executable) }} when running startproject. (Though 
>> on windows I that would be #!/usr/bin/env python.exe - not sure if that 
>> would work or not)
>>
>> On Mon, Apr 9, 2018 at 3:58 PM, Adam Johnson 
>> > wrote:
>>
>>> (Or would it work to use os.path.basename(sys.executable) ?)
>>>
>>>
>>> The shebang is interpreted by the OS so this is before python even 
>>> starts :)
>>>
>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/171caf56-a3cb-497d-9ebf-0a1ca61a31eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PEP 484 type hinting in Django

[Daniel Moisset]

A long due update on this, given that the question popped up recently:

I worked at some time in type annotations and published some for Django
1.10 ; I'm currently not working on them, given that my current work has
not been very close to Django development

After trying a few things, the best way to get this would be:
1) Add annotations upstream. Having to maintain a separate set of
annotations is probably not sustainable and will lead to errors. This of
course needs annotations accepted by the team.
1.1) Integrate typechecking into Django's build/CI process. This would
ensure that annotations are consistent with the implementation.
1.2) Annotations do not need to be exhaustive (and there are certainly
parts of Django which could benefit from them much more than others)
2) Generate stubs from the annotated source. This was not possible when I
wrote my stubs, but I've commited the mypy improvements with that feature.
2.1)A few stubs may need to be overridden manually from the autogenerated
(I found a few examples of this when I wrote my stubs)
3) Distribute annotated files separately (not with typeshed, and probably
not with django) so people can install the version they need. Distribution
of stubs has been problematic, PEP 561 should solve it but an
implementation for it has been just merged last week into mypy, and
probably released soon.

Before PEP561 and the ability to generate stubs, I don't believe it was
practical to make this project sustainable. At this time, it might be and
it can be a good time to restart this discussion.

Best,
D

On 6 April 2018 at 12:19, Florian Apolloner  wrote:

> To the best of my knowledge JetBrains fundled the money to Django for that
> specific purpose -- so yes the funding should be here if needed. That said,
> there is no decission on a) whether we actually want type hints and b) if
> the should be inline or stubs. Those two points have to be cleared first.
>
> Cheers,
> Florian
>
> On Friday, April 6, 2018 at 9:11:04 AM UTC+2, Eddy C wrote:
>>
>> Hi Tim, do you know if JetBrains still willing to fund the project as the
>> upcoming django 2.1 will only support python 3.5+ that pave the way for
>> inline annotations.
>>
>> On Wednesday, August 17, 2016 at 11:41:03 PM UTC+10, Tim Graham wrote:
>>>
>>> The JetBrains announcement that they want to fund the project isn't a
>>> guarantee that it'll be implemented. The feature needs to go through the
>>> normal feature acceptance process, which as Markus said, might involve a
>>> DEP.
>>>
>>> Assuming the idea is accepted, my sense on timing would be to wait until
>>> January when Django drops support for Python 2.7 and 3.4 in master. Then we
>>> could use inline annotations rather than the stub files.
>>>
>>> Past discussions of type hinting:
>>> https://groups.google.com/d/topic/django-developers/z_P1TvJ6
>>> QG8/discussion
>>> https://groups.google.com/d/topic/django-developers/xOTmq93Y
>>> ZuQ/discussion
>>>
>>> On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner
>>> wrote:



 On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote:
>
> @Florian
> Would you care to ellaborate? I couldn't find the post you mention
> (although requests is one of the few 3rd party projects that have support
> at the official typeshed repository, https://github.com
> /python/typeshed )
>

 https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/
 -- might be that things changed by now.

>>> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/6f2b5dd9-f8e6-4b67-8e25-
> 585cbd802413%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - UK Country Manager - Machinalis Limited
www.machinalis.co.uk 
Skype: @dmoisset T: + 44 7398 827139

1 Fore St, London, EC2Y 9DT

Machinalis Limited is a company registered in England and Wales. Registered
number: 10574987.

-- 
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 https://groups.google.com/group/djan

Re: Shouldn't manage.py call python3 instead of python?

[Florian Apolloner]

On Tuesday, April 10, 2018 at 1:28:33 PM UTC+2, Tim Allen wrote:
>
> Since `django-admin startproject my_project` is created on the fly from 
> templates, couldn't we dynamically create the `manage.py` executable based 
> on some system introspection and an agreed upon priority
>

Wouldn't that result in something along the lines of "works on my system" 
and breaks elsewhere? after all manage.py is committed into git more often 
than not.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4806c0b4-1f2a-4dd4-ba6d-4463004bc766%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should ModelChoiceIterator cache its QuerySet?

[Carlton Gibson]

Hi François, 

Thank you for a good write-up of the issue. 

Having looked at this from each direction I can't see a way of squaring all 
the desires here.

I see the possibility of an inconsistency between the __len__() and 
__iter__() calls. This would certainly be nice to avoid but I'm not sure it 
is the overriding concern here. 

I can easily see the memory issue being more significant than you're giving 
it credit for. 

The original issue (#23623) cited a ≈25% reduction in peak memory usage 
moving to the iterator. Choices are used in validation and not just 
template rendering. If not reset, the queryset is retained for the lifetime 
of the form instance, not just the ModelChoiceIterator iteration. With a 
large formset, with forms using ModelChoiceField on foreign keys with many 
thousands of records, the retained queryset would likely add up quickly. 

As such, I don't think we can just switch the default implementation. (I 
think we'd quickly see a lot of complaints.)

I **do see** the appeal of re-using the queryset for a whole lot of cases. 
Many times I would trade a bit more memory for the lifetime of a form 
instance for one less query. (Although, just personally, I'm not sure how 
often `if field.choices` actually comes up, for me.)

So, conclusions (with _I think we should…_ etc elided):

* Close your PR as is. https://github.com/django/django/pull/9867 — We 
can't just change the behaviour. 
* Look at Tim's PoC PR. https://github.com/django/django/pull/8649 — Can we 
implement __len__() to not _fetch_all()? Can we implement the custom 
__bool__ to avoid `count()`? Can we do that without an extra DB query? 
* If we **can't** avoid the extra query then we have to decide whether it's 
an acceptable price? 
* wontfix: If it's not, the existing behaviour is _OK_: it's not 
incorrect for __len__() to _fetch_all(), and your previous fix makes sure 
we don't waste that effort if it has been done. 
* Fix: I'd guess the extra query probably is OK, especially with an 
optimised __bool__ just checking existence. It's the price of consistency 
here. 
* Can we then document, and maybe provide, an alternate ModelChoiceIterator 
that just re-uses the queryset? 
* Advantages of this are consistency, fewer DB hits etc. 
* Cost is the higher memory use.

That's my take on the issue thus far. 

Kind Regards,

Carlton

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f8653583-4d19-4a06-9d68-f81639ea6937%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Aymeric Augustin]

> On 10 Apr 2018, at 17:43, Florian Apolloner  wrote:
> 
> On Tuesday, April 10, 2018 at 1:28:33 PM UTC+2, Tim Allen wrote:
> Since `django-admin startproject my_project` is created on the fly from 
> templates, couldn't we dynamically create the `manage.py` executable based on 
> some system introspection and an agreed upon priority
> 
> Wouldn't that result in something along the lines of "works on my system" and 
> breaks elsewhere? after all manage.py is committed into git more often than 
> not.

... which directs us to the correct solution: setting PYTHONPATH and 
DJANGO_SETTINGS_MODULE correctly and using django-admin instead of manage.py. 

pip / setuptools rewrites the shebang line appropriately when it installs the 
django-admin script. (I'm not sure how this happens exactly.)

My point is — there's no perfect solution. At best we can aim for a less 
imperfect solution than the status quo.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/C36A8494-1094-4A03-A402-618BB999F927%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: A more useful list of common passwords?

[Jessica F]

Hello! I'm Jessica, the assignee to this ticket. I am speaking on behalf of 
a group of newbies contributing to open source projects.
I was looking at the list of 20k passwords by Royce Williams, and there 
were 40 that were something like "$HEX[d0bfd197d5]". When I parsed them, 
nothing legible came out of it. I was wondering if this was an error on the 
list or was it intentional?

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a8043ddf-5147-44ba-b34a-85cb1596b7b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A more useful list of common passwords?

[Brenton Cleeland]

Hi Jessica (& team!),

My immediate thought is that those rows are errors. They should be ignored
and not included in any list added to Django :)

On 11 April 2018 at 02:13, Jessica F  wrote:

> Hello! I'm Jessica, the assignee to this ticket. I am speaking on behalf
> of a group of newbies contributing to open source projects.
> I was looking at the list of 20k passwords by Royce Williams, and there
> were 40 that were something like "$HEX[d0bfd197d5]". When I parsed them,
> nothing legible came out of it. I was wondering if this was an error on the
> list or was it intentional?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/django-developers/oMWLVK5kTpI/unsubscribe.
> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/a8043ddf-5147-44ba-b34a-
> 85cb1596b7b8%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Brenton

https://brntn.me // @sesh 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC_RtmsVGCO0KK4nBn%2Ba3tRU-9G5nkfD5g%3DjR-z_xhxad29hxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Bobby Mozumder]

In any case you’re going to see a lot of Django 2.0 developers on Mac OS hit 
this problem when they install to default Python or use standard Python install 
convention where Python 3.5 is installed as “python3".

-bobby

> On Apr 10, 2018, at 3:46 PM, Aymeric Augustin 
>  wrote:
> 
>> On 10 Apr 2018, at 17:43, Florian Apolloner > > wrote:
>> 
>> On Tuesday, April 10, 2018 at 1:28:33 PM UTC+2, Tim Allen wrote:
>> Since `django-admin startproject my_project` is created on the fly from 
>> templates, couldn't we dynamically create the `manage.py` executable based 
>> on some system introspection and an agreed upon priority
>> 
>> Wouldn't that result in something along the lines of "works on my system" 
>> and breaks elsewhere? after all manage.py is committed into git more often 
>> than not.
> 
> ... which directs us to the correct solution: setting PYTHONPATH and 
> DJANGO_SETTINGS_MODULE correctly and using django-admin instead of manage.py. 
> 
> pip / setuptools rewrites the shebang line appropriately when it installs the 
> django-admin script. (I'm not sure how this happens exactly.)
> 
> My point is — there's no perfect solution. At best we can aim for a less 
> imperfect solution than the status quo.
> 
> -- 
> 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/C36A8494-1094-4A03-A402-618BB999F927%40polytechnique.org
>  
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADE6613-965B-4A27-885A-EAE5651014A6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Josh Smeaton]

As a datapoint, I've seen roughly 1 person per week in #django IRC confused 
about specific startup exceptions due to them using python 2 rather than 
python 3 on Django >= 2.0. Unsure how many of these are due to the shebang. 
That said, it looks like there are no good solutions other than maybe 
ensuring our docs always show the form *python3 manage.py * rather 
than *./manage.py *.

On Wednesday, 11 April 2018 12:02:31 UTC+10, Bobby Mozumder wrote:
>
> In any case you’re going to see a lot of Django 2.0 developers on Mac OS 
> hit this problem when they install to default Python or use standard Python 
> install convention where Python 3.5 is installed as “python3".
>
> -bobby
>
> On Apr 10, 2018, at 3:46 PM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
> On 10 Apr 2018, at 17:43, Florian Apolloner  > wrote:
>
> On Tuesday, April 10, 2018 at 1:28:33 PM UTC+2, Tim Allen wrote:
>>
>> Since `django-admin startproject my_project` is created on the fly from 
>> templates, couldn't we dynamically create the `manage.py` executable based 
>> on some system introspection and an agreed upon priority
>>
>
> Wouldn't that result in something along the lines of "works on my system" 
> and breaks elsewhere? after all manage.py is committed into git more often 
> than not.
>
>
> ... which directs us to the correct solution: setting PYTHONPATH and 
> DJANGO_SETTINGS_MODULE correctly and using django-admin instead of 
> manage.py. 
>
> pip / setuptools rewrites the shebang line appropriately when it installs 
> the django-admin script. (I'm not sure how this happens exactly.)
>
> My point is — there's no perfect solution. At best we can aim for a less 
> imperfect solution than the status quo.
>
> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/C36A8494-1094-4A03-A402-618BB999F927%40polytechnique.org
>  
> 
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33ec0ccb-a63b-4451-bfec-815b9e5f52a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.