Re: Django 1.6 RC1 language key in session

Sounds like a good idea Miguel, please open a ticket or send a pull request that references the original ticket. Just wanted to clarify that the commit you referenced will be part of Django 1.7, not 1.6. On Tuesday, November 5, 2013 11:10:01 AM UTC-5, Miguel Araujo Pérez wrote: > > Hi there, >

Unexplicit 400 Bad Request even with DEBUG=True

Hi, I am using django 1.6rc1. and it seems that raising DisallowedModelAdminLookup in django/contrib/admin/views/main.py gives a very unexplicit 400 bad request, even in DEBUG=True. I eventually found the source of the problem, by diving into the code and sumbling upon http://stackoverflow.co

Django 1.6 RC1 language key in session

Hi there, Django 1.6 changes the key name that is used to store the language preferred by the user, due to the new name policies. This commit introduced it: https://github.com/django/django/commit/0d0f4f020afe516f23fd2305f13ff0a6a539b344 If you look at `django.views.i18n.set_language`

Re: Congo Curtis

On Tue, Nov 5, 2013 at 8:49 PM, Andre Terra wrote: > Congratulations indeed! As a once-frequent participant in #django and having > inspiring initiative. This is a very strong reason why I feel the need to > promote Django on a daily basis. ++1 -- Jasvir Singh Grewal www.jsgrewal.com -- Yo

Re: Congo Curtis

Congratulations indeed! As a once-frequent participant in #django and having asked you too many question, I feel this is a very well deserved recognition of your efforts to improve Django not only as a Python web framework but also as a community, most importantly. I must say that the Prize is fir

Re: Django 1.6RC1 exclude behavior change

Adding something about this to release notes shouldn't hurt anybody. I will aim for a more generic wording about changes in the ORM. For example, there are likely cases where the generated join aliases of the query aren't the same as they were in 1.5. This could affect .extra() users for examp

Re: Django 1.6RC1 exclude behavior change

I wouldn't ask for a bug that has long existed to be considered a release blocker. However a behavior change with no documentation is not a nice thing to do to your users, it seems to me Elyézer makes a good suggestion, informing users of the known bug in the release notes seems quite reasonable.

Re: Proposal to end the war with flake8 warnings

I've used autopep8 to make some additional cleanup -- see this pull request: https://github.com/django/django/pull/1875 -- 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

Re: Django 1.6RC1 exclude behavior change

Maybe it could be add to a "Known Bugs" or something like that section in the release notes? On Tue, Nov 5, 2013 at 3:42 AM, Anssi Kääriäinen wrote: > On Monday, November 4, 2013 8:16:12 PM UTC+2, jga...@gmail.com wrote: >> >> I was going to file a ticket in trac about this and found this one( >

Congo Curtis

Hello Curtis Maloney. Congratulations for winning Malcolm Tredinnick Memorial Prize. This tribute to Sir Malcolm is really remarkable. -- Jasvir Singh Grewal www.jsgrewal.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe