Re: Admin change list header for languages with grammatical cases

[Maciek Olko]

I forgot to mention that my implementation extensively uses gettext context
functionality [1]. I am happy to comment on and discuss particular parts of
the implementation.

The implementation is quite general, it does not limit the use of
attributes and contexts to only grammatical cases.

I decided to use "*accusative*" for attribute and context name hoping that
all languages will use base verbose name case or accusative grammatical
case. But on the other hand context/attribute name "*changelist title*"
would be probably equally good (the former would be better, if there would
be more uses than in changelist title only).

I think there comes natural expectation that similar mechanism would work
also in Django templates. That may be impossible because of dynamic nature
of this feature and serialization needed for safety and portability in
templates, although I'm not yet 100% sure.

Regards,
Maciej

[1]
https://docs.djangoproject.com/en/3.2/topics/i18n/translation/#contextual-markers

sob., 22 maj 2021 o 01:35 Maciek Olko  napisał(a):

> Admin’s change list headers are “Select {model} to change”, “Select
> {model} to view” or “Select {model}” (for pop-ups). We inject model’s
> verbose name in that strings. It renders correct strings for most of the
> languages, but not for those, which have grammatical cases [1] for nouns.
> Such languages include Polish, Greek, Russian, Hungarian, Czech and many
> more.
>
> I try to track how many of languages are affected for selected nouns in a
> spreadsheet [2] with help of Google Translate.
>
> To make the headers correct for this languages we should inject a verbose
> name into “Select {}[…]” sentences in a correct grammatical case.
> Effectively it is usually a word with changed ending comparing to a base
> form of a noun (verbose name value).
>
> I’d like to propose a backwards compatible way to support an ability to
> provide a translation for a grammatical case of model’s verbose name and
> “selecting” to use it in a translation string.
>
> In short the implementation requires:
>
>- switching from %-string formatting to format-strings in admin’s
>changelist headers source strings,
>- adding a class that will behave like string, but also let access
>it’s attributes,
>- leveraging accessing attributes in Python format-string syntax.
>
> You can see here the implementation concluded in 7 commits:
> https://github.com/django/django/compare/main...m-aciek:accusative-in-admin-header-approach-2
>
> I don’t have enough means to confirm it for all languages, but my cursory
> research says that probably the case used in “Select {}” sentence is an
> *accusative* for all languages that have grammatical cases.
>
> I would like that feature to be in Django as currently the admin
> changelist header translation, with model name not inflected, in Polish
> (“Wybierz użytkownik do zmiany”) sounds awkwardly and incorrectly. I'd
> assume for other such languages the situation is similar. Bringing
> grammatical cases there would be a great step towards perfection (that
> should attract perfectionists :) ) in admin for languages like Czech,
> Greek, Hungarian and many more.
>
> I didn’t post a ticket nor created a pull request yet, as I’d like to
> consult it with the community beforehand, according to the best practices.
>
> Would you accept such a functionality in the Django project?
>
> Best regards,
> Maciej Olko
>
> PS. There is a ticket about bringing gettext plurals into model’s verbose
> name [3] loosly connected with this particular topic, but the discussion
> underneath touches also the topic of grammatical cases.
>
> [1] https://en.wikipedia.org/wiki/Grammatical_case
> [2]
> https://docs.google.com/spreadsheets/d/1GfdCMvqCdg1c2fTf940r8yEnCiXr9s86p0JbGRV4Aio
> [3] https://code.djangoproject.com/ticket/11688
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALYYG83gh1s6uBrXaM0eCBfz8MYKu5i6p3LRrUaq2-m85-X1Ww%40mail.gmail.com.

Re: Translation of group permissions

[macie...@gmail.com]

Hi,

The permissions are stored in the database and don't get translated.

Refer: https://code.djangoproject.com/ticket/1688.

poniedziałek, 10 maja 2021 o 19:35:38 UTC+2 M Vv napisał(a):

> Translation of user permissions is not done.
>
> [image: gruop trans.PNG]
>
> How should it go about it?
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/da4f96c9-d780-4dde-8ae8-d6c7f0ef59b7n%40googlegroups.com.

Admin change list header for languages with grammatical cases

[Maciek Olko]

Admin’s change list headers are “Select {model} to change”, “Select {model}
to view” or “Select {model}” (for pop-ups). We inject model’s verbose name
in that strings. It renders correct strings for most of the languages, but
not for those, which have grammatical cases [1] for nouns. Such languages
include Polish, Greek, Russian, Hungarian, Czech and many more.

I try to track how many of languages are affected for selected nouns in a
spreadsheet [2] with help of Google Translate.

To make the headers correct for this languages we should inject a verbose
name into “Select {}[…]” sentences in a correct grammatical case.
Effectively it is usually a word with changed ending comparing to a base
form of a noun (verbose name value).

I’d like to propose a backwards compatible way to support an ability to
provide a translation for a grammatical case of model’s verbose name and
“selecting” to use it in a translation string.

In short the implementation requires:

   - switching from %-string formatting to format-strings in admin’s
   changelist headers source strings,
   - adding a class that will behave like string, but also let access it’s
   attributes,
   - leveraging accessing attributes in Python format-string syntax.

You can see here the implementation concluded in 7 commits:
https://github.com/django/django/compare/main...m-aciek:accusative-in-admin-header-approach-2

I don’t have enough means to confirm it for all languages, but my cursory
research says that probably the case used in “Select {}” sentence is an
*accusative* for all languages that have grammatical cases.

I would like that feature to be in Django as currently the admin changelist
header translation, with model name not inflected, in Polish (“Wybierz
użytkownik do zmiany”) sounds awkwardly and incorrectly. I'd assume for
other such languages the situation is similar. Bringing grammatical cases
there would be a great step towards perfection (that should attract
perfectionists :) ) in admin for languages like Czech, Greek, Hungarian and
many more.

I didn’t post a ticket nor created a pull request yet, as I’d like to
consult it with the community beforehand, according to the best practices.

Would you accept such a functionality in the Django project?

Best regards,
Maciej Olko

PS. There is a ticket about bringing gettext plurals into model’s verbose
name [3] loosly connected with this particular topic, but the discussion
underneath touches also the topic of grammatical cases.

[1] https://en.wikipedia.org/wiki/Grammatical_case
[2]
https://docs.google.com/spreadsheets/d/1GfdCMvqCdg1c2fTf940r8yEnCiXr9s86p0JbGRV4Aio
[3] https://code.djangoproject.com/ticket/11688

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALYYG838Fv1DvY3o7M84z-%3DfKnFQr0JHyc1N7XHjjPBf_UcQbA%40mail.gmail.com.

Re: Should there be a default lockfile location for SerializeMixin?

['Mike Lissner' via Django developers (Contributions to Django itself)]

> you will degrade to *worse than single process* speed.

I guess this is true in a technical sense, but is it true in a noticeable 
sense? Yes, having lots of processes vying for a lock isn't great, but I'd 
be surprised if it adds up to very much. Am I wrong about this? 

> This would silently degrade parallel tests to serial performance if 
SerialMixin was incorrectly configured.

Well, not *silently*, right? Isn't the whole point of SerialMixin precisely 
*to* degrade tests to serial performance? If you're using it, that's 
exactly what you're after right? My thought is that by default it should 
fully serialize tests it's mixed into, and that by configuring a different 
file (or "__file__", say), you can create sub-groups of tests that must run 
serially (while others can continue in other processes). Maybe I'm missing 
a piece of the puzzle here? 

(Nice fix in the PR, thanks.)
On Friday, May 21, 2021 at 2:43:12 AM UTC-7 Adam Johnson wrote:

> 1. Should we tweak the docs to show something like the above, that would 
>> make the solution there easier to just drop in?
>>
>
> I don't think so. Locking is a last resort and ruins performance - if used 
> across your whole test suite you will degrade to *worse than single 
> process* speed. You should instead try to isolate your resources per 
> process, e.g. by mixing os.getpid() in resource names.
>
> I don't think Django should provide much more than it already does - if I 
> was to make a default for SerializeMixin it would be __file__ as the docs 
> suggest, but that's a bit hard since __file__ is dynamic per module.
>
> 2. Would it be crazy to upgrade the SerailzeMixin so that if lockfile is 
>> left out, it finds some standard file in every django project and uses that 
>> for the locking? If it worked that way, switching to parallel tests would 
>> just mean using the `--parallel` flag, identifying tests that failed, and 
>> mixing in the SerializeMixin into each of those tests. It'd be much easier. 
>> Currently if the property is missing, you get a ValueError.
>>
>
> I don't think it would be sensible to use a "standard file". This would 
> silently degrade parallel tests to serial performance if SerialMixin was 
> incorrectly configured.
>
> Instead, we can shift the check for the lockfile attribute to import time. 
> Then you don't need to go through a whole test run to find misconfigured 
> tests. I've made a PR for that here: 
> https://github.com/django/django/pull/14427 
>
> Thanks,
>
> Adam
>
> On Fri, 21 May 2021 at 01:36, 'Mike Lissner' via Django developers 
> (Contributions to Django itself)  wrote:
>
>> I spent the day today making the tests for my project run in parallel. As 
>> part of that, I had my first encounter with the SerializeMixin, which you 
>> can use in conjunction with the `--parallel` flag to ensure that certain 
>> tests don't run at the same time. It's neat, in theory:
>>
>>
>> https://docs.djangoproject.com/en/3.2/topics/testing/advanced/#enforce-running-test-classes-sequentially
>>
>> One thing I found kind of lacking about it is that it didn't easily solve 
>> my main problem. What I wanted to do was to just mark meddlesome tests to 
>> run serially. To do that though is kind of tricky. The way I eventually did 
>> so was to set lockfile as:
>>
>> lockfile = Path(__file__).parents[1] / "settings.py"
>>
>> I didn't find many others using SerializeMixin online (searching Github 
>> and Google), which surprised me, and I didn't see any other solutions like 
>> mine when I looked either. It sort of felt like an under-used tool.
>>
>> The way it works now, you use the SerializeMixin in your test class, and 
>> then you set up a property on the class called `lockfile`, that points to a 
>> file that is used to lock the tests so none others can run at the same 
>> time. 
>>
>> The docs show an example that has `lockfile = __file__`, which I thought 
>> I could just sprinkle into my meddlesome tests to fix them. Unfortunately, 
>> that just locks different classes within a single tests.py file, so I had 
>> to do the solution above. 
>>
>> A couple thougths:
>>
>> 1. Should we tweak the docs to show something like the above, that would 
>> make the solution there easier to just drop in?
>>
>> 2. Would it be crazy to upgrade the SerailzeMixin so that if lockfile is 
>> left out, it finds some standard file in every django project and uses that 
>> for the locking? If it worked that way, switching to parallel tests would 
>> just mean using the `--parallel` flag, identifying tests that failed, and 
>> mixing in the SerializeMixin into each of those tests. It'd be much easier. 
>> Currently if the property is missing, you get a ValueError.
>>
>> Thoughts? 
>>
>> Mike
>>
>>
>> -- 
>> 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 

Re: GSoC Proposal: (Migrations) Adapt schema editors to operate from model states instead of fake rendered models.

[Carlton Gibson]

Hi Manav. Welcome aboard! 

On Thursday, 20 May 2021, Manav Agarwal  wrote:

> Hello everyone,
> I am so very thankful to everyone who helped me out with my project idea
> and proposal. The proposal is accepted and I will give my best to
> accomplish as I have promised.
> On Thursday, April 8, 2021 at 7:17:58 AM UTC+5:30 Manav Agarwal wrote:
>
>> Hey Carlton.
>>
>> I have submitted the proposal.
>> Also, Your suggestion of adding tests with the introduction of a new
>> central registry seems great and I have implemented the same in phase 1.
>> Also, I already added all the points suggested by Simon Charette from the
>> discussion(https://groups.google.com/g/django-developers/c/_ohBzsuomqw/m/
>> cEI8eoK7BQAJ).
>> Last but not least, I will try to make my proposal more clear in the
>> coming week till the deadline.
>> I understand that as the proposal is detailed you will have to sit down
>> with it more fully but you don't have time for the same and It's totally
>> fine.
>>
>> Thank You for your suggestions that always help a lot.
>>
>>
>> On Wed, Apr 7, 2021 at 7:09 PM Carlton Gibson 
>> wrote:
>>
>>> Hi Manav.
>>>
>>> You should definitely submit. Your proposal is quite detailed, so I'd
>>> need to sit down with it more fully than I have time to comment on this
>>> week.
>>> (But that's OK — even if your implementation idea needs revision, THAT
>>> you've considered it is important.)
>>>
>>> Having said that:
>>>
>>> * You have "testing & docs" tacked on at the end in your schedule.
>>> Identify the phases and include time to write the tests as you go. In phase
>>> 1, how will you know that your central registry is correctly tracking model
>>> relationships unless you write tests? (You won't...)
>>>
>>> * Maybe you did this already but, review the points Simon Charette made
>>> in the thread on this topic last year: https://groups.google.com/g/
>>> django-developers/c/_ohBzsuomqw/m/cEI8eoK7BQAJ — There are large parts
>>> of a solution to this problem there. It would be good if on review your
>>> proposal uses Simon's suggestions.
>>>
>>> Please do use this week to make your proposal as good as you can and
>>> submit. (I can't see that I'll have capacity to review another draft, but
>>> equally you should have enough to go on now.)
>>>
>>> I wish you luck!
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> On Wednesday, 7 April 2021 at 08:13:54 UTC+2 dpsma...@gmail.com wrote:
>>>
 Thank You Carlton for the feedback.

 As per your suggestion, I have increased the clarity of the proposal
 
 with some code and implementation. I will try to maximize the clarity as
 much as possible.

 Till then, May you please suggest, that Shall I share my proposal as a
 draft at GSoC Portal .

 Also, it would be great if you may suggest the possible improvement
 areas in the proposal
 ,
 or does it seems fine?

 Regards
 Manav Agarwal

 On Tue, Apr 6, 2021 at 7:09 PM Carlton Gibson 
 wrote:

> Hi Manav.
>
> Sorry for the late reply.
>
> Your proposal looks very good, and your previous contributions are
> noticed.
> You’ve obviously taken time to look at it in depth.
>
> I think just going over it this week as time allows to maximise
> clarity is worth it. That’s always time well spent. (Generally there are a
> lot of applications, so making yours stand out as focused and to the point
> both demonstrates your capacity and makes the reviewer’s job easier.)
>
> I hope that helps.
>
> Kind regards, Carlton
>
> On Mon, 5 Apr 2021 at 05:12, Manav Agarwal  wrote:
>
>> Link for the proposal - https://gist.github.com/manav014/
>> 9b0feb734e4d140eef1913340602d2ae
>>
>> On Monday, April 5, 2021 at 8:41:32 AM UTC+5:30 Manav Agarwal wrote:
>>
>>> I have added the proposed solution in the proposal.
>>> I request fellow developers to please help me with their respective
>>> suggestions, thoughts or feedback, so that I may develop a better and
>>> practical proposal.
>>>
>>> Regards,
>>> Manav Agarwal
>>>
>>> On Friday, April 2, 2021 at 3:09:46 AM UTC+5:30 Manav Agarwal wrote:
>>>
 Hello everyone,
 My name is Manav. I’m a Computer Science and Engineering junior at
 Dr. A.P.J. Abdul Kalam Technical University in India.
 I started contributing to Django in October 2020 and have solved
 many issues on trac
 
 .
 I read through the GSoC Idea List and the Migration topic stood out
 for me. I found the idea to adapt schema editors to operate from model
 

Re: making TemplateView.template_name point to a file NOT in the templates directory.

[Sharif Mehedi]

Hi Adam,

Thank you for taking your time to reply on this. I thought that this problem 
was really too complicated. And at the time of desperation thought that it was 
a good idea to ask it in here since people here are more experienced with 
django internals, even though I knew it was the wrong place. Excuse me if I 
have over reached. A little later posting this mail I found out about the 
TEMPLATES DIRS key and immediately regretted posting in here, although decided 
against using the DIRS key.
But I am glad that you've answered so politely.Thank you,Sharif
   On Friday, May 21, 2021, 4:51:15 PM GMT+6, 'Adam Johnson' via Django 
developers (Contributions to Django itself) 
 wrote:  
 
 Hi!

I think you've found the wrong mailing list for this post. This mailing list is 
for discussing the development of Django itself, not for support using Django. 
This means the discussions of bugs and features in Django itself, rather than 
in your code using it. People on this list are unlikely to answer your support 
query with their limited time and energy.

For support, please follow the "Getting Help" page: 
https://docs.djangoproject.com/en/3.1/faq/help/ . This will help you find 
people who are willing to support you, and to ask your question in a way that 
makes it easy for them to answer.
I think perhaps you are looking for the DIRS key in the TEMPLATES setting, but 
a clearer question in one of the help channels would clarify your requirements.
Thanks for your understanding and all the best,

Adam
On Thu, 20 May 2021 at 18:38, Sharif Mehedi  wrote:

I do not have a django-admin project and using django views (along with other 
django submodules) in my python app, so, i do not have a directory structure 
like django projects has and I never had a templates directory in my app. The 
way we configured it, serving from templates directory is out of the question.
I want to know, if there's an easy solution in making django take a 
template_name as (django.views.generic.base).TemplateView.template_name that is 
(simply said) outside the templates directory.
TIARegards,Sharif

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/082f893b-5f32-4641-a786-7b1dff51ce4an%40googlegroups.com.



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0XD7ivtpiQxgmfjcBvaywzQtTLf%3DVL%3De9MvS7nL-2qDw%40mail.gmail.com.
  

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1591794295.322908.1621613198139%40mail.yahoo.com.

Re: making TemplateView.template_name point to a file NOT in the templates directory.

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.1/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

I think perhaps you are looking for the DIRS key in the TEMPLATES setting,
but a clearer question in one of the help channels would clarify your
requirements.

Thanks for your understanding and all the best,

Adam

On Thu, 20 May 2021 at 18:38, Sharif Mehedi 
wrote:

> I do not have a django-admin project and using django views (along with
> other django submodules) in my python app, so, i do not have a directory
> structure like django projects has and I never had a templates directory in
> my app. The way we configured it, serving from templates directory is out
> of the question.
>
> I want to know, if there's an easy solution in making django take a
> template_name as (django.views.generic.base).TemplateView.template_name
> that is (simply said) outside the templates directory.
>
> TIA
> Regards,
> Sharif
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/082f893b-5f32-4641-a786-7b1dff51ce4an%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0XD7ivtpiQxgmfjcBvaywzQtTLf%3DVL%3De9MvS7nL-2qDw%40mail.gmail.com.

Re: Should there be a default lockfile location for SerializeMixin?

['Adam Johnson' via Django developers (Contributions to Django itself)]

> 1. Should we tweak the docs to show something like the above, that would
> make the solution there easier to just drop in?
>

I don't think so. Locking is a last resort and ruins performance - if used
across your whole test suite you will degrade to *worse than single
process* speed. You should instead try to isolate your resources per
process, e.g. by mixing os.getpid() in resource names.

I don't think Django should provide much more than it already does - if I
was to make a default for SerializeMixin it would be __file__ as the docs
suggest, but that's a bit hard since __file__ is dynamic per module.

2. Would it be crazy to upgrade the SerailzeMixin so that if lockfile is
> left out, it finds some standard file in every django project and uses that
> for the locking? If it worked that way, switching to parallel tests would
> just mean using the `--parallel` flag, identifying tests that failed, and
> mixing in the SerializeMixin into each of those tests. It'd be much easier.
> Currently if the property is missing, you get a ValueError.
>

I don't think it would be sensible to use a "standard file". This would
silently degrade parallel tests to serial performance if SerialMixin was
incorrectly configured.

Instead, we can shift the check for the lockfile attribute to import time.
Then you don't need to go through a whole test run to find misconfigured
tests. I've made a PR for that here:
https://github.com/django/django/pull/14427

Thanks,

Adam

On Fri, 21 May 2021 at 01:36, 'Mike Lissner' via Django developers
(Contributions to Django itself)  wrote:

> I spent the day today making the tests for my project run in parallel. As
> part of that, I had my first encounter with the SerializeMixin, which you
> can use in conjunction with the `--parallel` flag to ensure that certain
> tests don't run at the same time. It's neat, in theory:
>
>
> https://docs.djangoproject.com/en/3.2/topics/testing/advanced/#enforce-running-test-classes-sequentially
>
> One thing I found kind of lacking about it is that it didn't easily solve
> my main problem. What I wanted to do was to just mark meddlesome tests to
> run serially. To do that though is kind of tricky. The way I eventually did
> so was to set lockfile as:
>
> lockfile = Path(__file__).parents[1] / "settings.py"
>
> I didn't find many others using SerializeMixin online (searching Github
> and Google), which surprised me, and I didn't see any other solutions like
> mine when I looked either. It sort of felt like an under-used tool.
>
> The way it works now, you use the SerializeMixin in your test class, and
> then you set up a property on the class called `lockfile`, that points to a
> file that is used to lock the tests so none others can run at the same
> time.
>
> The docs show an example that has `lockfile = __file__`, which I thought I
> could just sprinkle into my meddlesome tests to fix them. Unfortunately,
> that just locks different classes within a single tests.py file, so I had
> to do the solution above.
>
> A couple thougths:
>
> 1. Should we tweak the docs to show something like the above, that would
> make the solution there easier to just drop in?
>
> 2. Would it be crazy to upgrade the SerailzeMixin so that if lockfile is
> left out, it finds some standard file in every django project and uses that
> for the locking? If it worked that way, switching to parallel tests would
> just mean using the `--parallel` flag, identifying tests that failed, and
> mixing in the SerializeMixin into each of those tests. It'd be much easier.
> Currently if the property is missing, you get a ValueError.
>
> Thoughts?
>
> Mike
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/70ac0aec-f1a5-4bdb-876d-582e75168820n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM302y5Nu_ave-bAJgd_dLQkETzyBTvsDgWxXUBsRSisOA%40mail.gmail.com.