Re: Guessable entry points

[Aymeric Augustin]

`python -m django` as a alias for `django-admin` sounds good.

-- 
Aymeric.



> On 30 avr. 2015, at 19:15, Ryan Hiebert  wrote:
> 
> https://github.com/django/django/pull/4588 
> 
> 
> I this PR I suggest to add a `django` entry point that is identical to 
> `django-admin`, and a `__main__.py` that also is a mirror of `django-admin`.
> 
> There’s also related discussion at https://github.com/django/django/pull/3861 
> 
> 
> There’s precedent for using these as the primary methods of use all over the 
> place. Flask, in particular, uses both the `flask` command as well as `python 
> -m flask`. Celery also uses the `celery` command as well as `python -m 
> celery`.
> 
> 
> I see value in adding these endpoints that are more easily guessable. 
> However, there’s a cost too, the cost of having more than one way to do it. 
> We already have `django-admin` and `django-admin.py`, would adding these 
> obvious entry points give too many options?
> 
> Ryan
> 
> -- 
> 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/90DC7B87-35F5-4B77-93EA-7734DA31EA86%40ryanhiebert.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/37733725-6295-48F4-98D1-BC82978EE570%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Pass exception to error handlers

[Claude Paroz]

New ticket created: https://code.djangoproject.com/ticket/24733

Claude

-- 
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/cba8b8a1-a698-4474-8ec0-d4bf34639dde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Guessable entry points

[Michael Manfre]

I like the alias.

On Fri, May 1, 2015 at 5:58 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> `python -m django` as a alias for `django-admin` sounds good.
>
> --
> Aymeric.
>
>
>
> On 30 avr. 2015, at 19:15, Ryan Hiebert  wrote:
>
> https://github.com/django/django/pull/4588
>
> I this PR I suggest to add a `django` entry point that is identical to
> `django-admin`, and a `__main__.py` that also is a mirror of `django-admin`.
>
> There’s also related discussion at
> https://github.com/django/django/pull/3861
>
> There’s precedent for using these as the primary methods of use all over
> the place. Flask, in particular, uses both the `flask` command as well as
> `python -m flask`. Celery also uses the `celery` command as well as `python
> -m celery`.
>
>
> I see value in adding these endpoints that are more easily guessable.
> However, there’s a cost too, the cost of having more than one way to do it.
> We already have `django-admin` and `django-admin.py`, would adding these
> obvious entry points give too many options?
>
> Ryan
>
> --
> 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/90DC7B87-35F5-4B77-93EA-7734DA31EA86%40ryanhiebert.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/37733725-6295-48F4-98D1-BC82978EE570%40polytechnique.org
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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/CAGdCwBtZbmwE1hU-5knGR-OPO23Y35wZ5cV2ygDOK7aaPTUt1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Guessable entry points

[Enrique Paredes]

So along this line of thought,  `django-admin` is a good command name? 





To me the admin, in the django world is a clear distint concept to what this 
command does.




Besides to be used to it, seems more natural to call it `django`. 




Cheers,

E.

On Fri, May 1, 2015 at 2:33 PM, Michael Manfre  wrote:

> I like the alias.
> On Fri, May 1, 2015 at 5:58 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>> `python -m django` as a alias for `django-admin` sounds good.
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 30 avr. 2015, at 19:15, Ryan Hiebert  wrote:
>>
>> https://github.com/django/django/pull/4588
>>
>> I this PR I suggest to add a `django` entry point that is identical to
>> `django-admin`, and a `__main__.py` that also is a mirror of `django-admin`.
>>
>> There’s also related discussion at
>> https://github.com/django/django/pull/3861
>>
>> There’s precedent for using these as the primary methods of use all over
>> the place. Flask, in particular, uses both the `flask` command as well as
>> `python -m flask`. Celery also uses the `celery` command as well as `python
>> -m celery`.
>>
>>
>> I see value in adding these endpoints that are more easily guessable.
>> However, there’s a cost too, the cost of having more than one way to do it.
>> We already have `django-admin` and `django-admin.py`, would adding these
>> obvious entry points give too many options?
>>
>> Ryan
>>
>> --
>> 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/90DC7B87-35F5-4B77-93EA-7734DA31EA86%40ryanhiebert.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/37733725-6295-48F4-98D1-BC82978EE570%40polytechnique.org
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
> -- 
> 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/CAGdCwBtZbmwE1hU-5knGR-OPO23Y35wZ5cV2ygDOK7aaPTUt1w%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/1430488299401.034ca1d9%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.

Re: Guessable entry points

[Florian Apolloner]

On Friday, May 1, 2015 at 3:51:50 PM UTC+2, Enrique Paredes wrote:
>
>  So along this line of thought,  `django-admin` is a good command name? 
>

Does not really matter imo, that is what we have now and we should not 
change this without a really good reason.

Cheers,
Florian

-- 
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/903126b8-4ce6-44b8-8db6-c043b45f3fb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Guessable entry points

[Aymeric Augustin]

On 1 mai 2015, at 15:51, Enrique Paredes  wrote:

> So along this line of thought,  `django-admin` is a good command name? 

Well, it’s a reasonably unambiguous way to refer to the django-admin command, 
which is good for the docs.

“django” is more ambiguous: it can refer to the framework itself (although 
incorrectly capitalized) or to the top-level Python package.

-- 
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/98213CAF-69E0-4CDF-AD66-86F3B3A2D5C6%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Guessable entry points

[Marc Tamlyn]

Yes to python -m django
No to django as another alias for django-admin. After all, someone who is
just "guessing" will probably type dj and get django-admin[.py] anyway.

On 1 May 2015 at 15:03, Aymeric Augustin  wrote:

> On 1 mai 2015, at 15:51, Enrique Paredes  wrote:
>
> > So along this line of thought,  `django-admin` is a good command name?
>
> Well, it’s a reasonably unambiguous way to refer to the django-admin
> command, which is good for the docs.
>
> “django” is more ambiguous: it can refer to the framework itself (although
> incorrectly capitalized) or to the top-level Python package.
>
> --
> 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/98213CAF-69E0-4CDF-AD66-86F3B3A2D5C6%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FKc4RJaSkT1V9ZVKskGWt1tFE5o4pOVZfZxpc2W84ALQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Rename *SSL* settings to *TLS*

[Hugo Osvaldo Barrera]

After searching through the documentation for a few TLS related settings, I
failed to find anything. A while later, I found them as *SSL*.

I'd like to suggest renaming settings that mention SSL to TLS, to reflect that
the former is now deprecated.

   eg: SECURE_PROXY_SSL_HEADER -> SECURE_PROXY_TLS_HEADER

This should improve the ability for new users to find these settings, and
reflect current practices (eg: that SSL has been completely deprecated in
favour of TLS).

Any opinions or complaints to this?

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?

-- 
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/20150501141621.GA9246%40athena.barrera.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Rename *SSL* settings to *TLS*

[Collin Anderson]

I don't think it's really worth changing, but if anything, I'd recommend 
HTTPS rather than TLS, as that doesn't care about the underlying protocol 
which may change again in the future. Or maybe go with PROXY_SCHEME_HEADER 
or something.

On Friday, May 1, 2015 at 12:23:32 PM UTC-4, Hugo Osvaldo Barrera wrote:
>
> After searching through the documentation for a few TLS related settings, 
> I 
> failed to find anything. A while later, I found them as *SSL*. 
>
> I'd like to suggest renaming settings that mention SSL to TLS, to reflect 
> that 
> the former is now deprecated. 
>
>eg: SECURE_PROXY_SSL_HEADER -> SECURE_PROXY_TLS_HEADER 
>
> This should improve the ability for new users to find these settings, and 
> reflect current practices (eg: that SSL has been completely deprecated in 
> favour of TLS). 
>
> Any opinions or complaints to this? 
>
> -- 
> Hugo Osvaldo Barrera 
> A: Because we read from top to bottom, left to right. 
> Q: Why should I start my reply below the quoted text? 
>

-- 
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/f17dcfa9-ad15-4fb7-9efc-c54053636e4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Redirect loop detection in test client is incorrect

[Mounir Messelmeni]

This is related to the ticket #24713, I'm trying to fix this issue and I 
was thinking about using a variable to know how much time a single url can 
be repeated on the redirects.
Is two time sufficient or we will have another case that need 3 times.
If you agree using a variable is it okay to pass it like the follow on the 
get/post/head/trace/put method of the test client (max_page_redirect) and 
make it by default 2 or store it on the settings ?

def put(self, path, data='', content_type='application/octet-stream',
follow=False, max_page_redirect=2,
secure=False, **extra):
"""
Send a resource to the server using PUT.
"""
response = super(Client, self).put(path, data=data,
   content_type=content_type,
   secure=secure, **extra)
if follow:
response = self._handle_redirects(response, max_page_redirect,
  **extra)
return response


-- 
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/803ceae0-70a0-4aa2-9c32-046230e65587%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Redirect loop detection in test client is incorrect

[Tim Graham]

Is there any disadvantage to making it some "large" number like 10? In that 
case it probably wouldn't need to be configurable. The additional time to 
do 10 loops instead of 2 is probably trivial (and it's an unexpected 
condition anyway).

On Friday, May 1, 2015 at 1:36:32 PM UTC-4, Mounir Messelmeni wrote:
>
> This is related to the ticket #24713, I'm trying to fix this issue and I 
> was thinking about using a variable to know how much time a single url can 
> be repeated on the redirects.
> Is two time sufficient or we will have another case that need 3 times.
> If you agree using a variable is it okay to pass it like the follow on the 
> get/post/head/trace/put method of the test client (max_page_redirect) and 
> make it by default 2 or store it on the settings ?
>
> def put(self, path, data='', content_type='application/octet-stream',
> follow=False, max_page_redirect=2,
> secure=False, **extra):
> """
> Send a resource to the server using PUT.
> """
> response = super(Client, self).put(path, data=data,
>content_type=content_type,
>secure=secure, **extra)
> if follow:
> response = self._handle_redirects(response, max_page_redirect,
>   **extra)
> return response
>
>
>

-- 
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/5e0c0083-ada0-4738-ad37-9a923d53f9aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Redirect loop detection in test client is incorrect

[Mounir Messelmeni]

I think 10 is already too much, it about redirecting to the same page N 
times. Page1 to Page, Page2 to Page3 and Page3 to the Page1: N=2 redirects 
to the Page1.
Do you think 10 times make senses? In my opinion it's too much and the need 
to raise an error to make developers know about something wrong in their 
redirects else they can override it for an extreme purpose.

On Friday, May 1, 2015 at 7:54:44 PM UTC+2, Tim Graham wrote:
>
> Is there any disadvantage to making it some "large" number like 10? In 
> that case it probably wouldn't need to be configurable. The additional time 
> to do 10 loops instead of 2 is probably trivial (and it's an unexpected 
> condition anyway).
>
> On Friday, May 1, 2015 at 1:36:32 PM UTC-4, Mounir Messelmeni wrote:
>>
>> This is related to the ticket #24713, I'm trying to fix this issue and I 
>> was thinking about using a variable to know how much time a single url can 
>> be repeated on the redirects.
>> Is two time sufficient or we will have another case that need 3 times.
>> If you agree using a variable is it okay to pass it like the follow on 
>> the get/post/head/trace/put method of the test client (max_page_redirect) 
>> and make it by default 2 or store it on the settings ?
>>
>> def put(self, path, data='', content_type='application/octet-stream',
>> follow=False, max_page_redirect=2,
>> secure=False, **extra):
>> """
>> Send a resource to the server using PUT.
>> """
>> response = super(Client, self).put(path, data=data,
>>content_type=content_type,
>>secure=secure, **extra)
>> if follow:
>> response = self._handle_redirects(response, max_page_redirect,
>>   **extra)
>> return response
>>
>>
>>

-- 
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/262d5e93-57cb-48ec-80b8-13504744022e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

[Andreas Pelme]

Hi,

> On 30 apr 2015, at 18:42, Carl Meyer  wrote:
> 
> transaction-hooks is actually fairly small and understandable too. And I
> don't think it's hard to use for this situation, either; you'd just need
> to use `connection.on_commit` in your signal handler if you wanted to
> delay some action until post-commit.
> 
>> Unless it's going to be super easy to port transaction-hooks over, I
>> think it might be nice to get this in and sealed (it's not adding too
>> much more complexity). If transaction-hooks would land in core well,
>> let's do that.
> 
> I don't think landing transaction-hooks in core for 1.9 would be hard at
> all, and no-one has objected to the idea (AFAIK). I (or anyone really)
> just need to get around to it. Motivation has been low so far mostly
> because it works fine as an external add-on.


I did an initial port of django-transaction-hooks, it was pretty 
straightforward. All the hard work has already been done. :-)

Here is the PR: https://github.com/django/django/pull/4593

The patch is not yet finished (there’s a todo-list at the PR with some missing 
pieces). Let me know what you think and I’ll be happy to continue working on a 
proper patch to get it into a merge-able state.

Cheers,
Andreas

-- 
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/5A9C5A84-A28C-4556-BD7F-7F1699A166AA%40pelme.se.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Redirect loop detection in test client is incorrect

[Mounir Messelmeni]

We've already the max total redirects counts it's 20

if len(redirect_chain) > 20:
# Such a lengthy chain likely also means a loop, but one with
# a growing path, changing view, or changing query argument;
# 20 is the value of "network.http.redirection-limit" from Firefox.
raise RedirectCycleError("Too many redirects.", last_response=response)



On Friday, May 1, 2015 at 8:24:48 PM UTC+2, Mounir Messelmeni wrote:
>
> I think 10 is already too much, it about redirecting to the same page N 
> times. Page1 to Page, Page2 to Page3 and Page3 to the Page1: N=2 redirects 
> to the Page1.
> Do you think 10 times make senses? In my opinion it's too much and the 
> need to raise an error to make developers know about something wrong in 
> their redirects else they can override it for an extreme purpose.
>
> On Friday, May 1, 2015 at 7:54:44 PM UTC+2, Tim Graham wrote:
>>
>> Is there any disadvantage to making it some "large" number like 10? In 
>> that case it probably wouldn't need to be configurable. The additional time 
>> to do 10 loops instead of 2 is probably trivial (and it's an unexpected 
>> condition anyway).
>>
>> On Friday, May 1, 2015 at 1:36:32 PM UTC-4, Mounir Messelmeni wrote:
>>>
>>> This is related to the ticket #24713, I'm trying to fix this issue and I 
>>> was thinking about using a variable to know how much time a single url can 
>>> be repeated on the redirects.
>>> Is two time sufficient or we will have another case that need 3 times.
>>> If you agree using a variable is it okay to pass it like the follow on 
>>> the get/post/head/trace/put method of the test client (max_page_redirect) 
>>> and make it by default 2 or store it on the settings ?
>>>
>>> def put(self, path, data='', content_type='application/octet-stream',
>>> follow=False, max_page_redirect=2,
>>> secure=False, **extra):
>>> """
>>> Send a resource to the server using PUT.
>>> """
>>> response = super(Client, self).put(path, data=data,
>>>content_type=content_type,
>>>secure=secure, **extra)
>>> if follow:
>>> response = self._handle_redirects(response, 
>>> max_page_redirect,
>>>   **extra)
>>> return response
>>>
>>>
>>>

-- 
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/c0329e08-f207-46e7-9c78-83dfeeccc544%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Redirect loop detection in test client is incorrect

[Tim Graham]

My thinking is that a redirect loop of n>2 doesn't seem likely to exit on 
its own if the developer doesn't intend it to, thus the n we pick shouldn't 
really matter.

On Friday, May 1, 2015 at 2:27:57 PM UTC-4, Mounir Messelmeni wrote:
>
> We've already the max total redirects counts it's 20
>
> if len(redirect_chain) > 20:
> # Such a lengthy chain likely also means a loop, but one with
> # a growing path, changing view, or changing query argument;
> # 20 is the value of "network.http.redirection-limit" from Firefox.
> raise RedirectCycleError("Too many redirects.", last_response=response)
>
>
>
> On Friday, May 1, 2015 at 8:24:48 PM UTC+2, Mounir Messelmeni wrote:
>>
>> I think 10 is already too much, it about redirecting to the same page N 
>> times. Page1 to Page, Page2 to Page3 and Page3 to the Page1: N=2 redirects 
>> to the Page1.
>> Do you think 10 times make senses? In my opinion it's too much and the 
>> need to raise an error to make developers know about something wrong in 
>> their redirects else they can override it for an extreme purpose.
>>
>> On Friday, May 1, 2015 at 7:54:44 PM UTC+2, Tim Graham wrote:
>>>
>>> Is there any disadvantage to making it some "large" number like 10? In 
>>> that case it probably wouldn't need to be configurable. The additional time 
>>> to do 10 loops instead of 2 is probably trivial (and it's an unexpected 
>>> condition anyway).
>>>
>>> On Friday, May 1, 2015 at 1:36:32 PM UTC-4, Mounir Messelmeni wrote:

 This is related to the ticket #24713, I'm trying to fix this issue and 
 I was thinking about using a variable to know how much time a single url 
 can be repeated on the redirects.
 Is two time sufficient or we will have another case that need 3 times.
 If you agree using a variable is it okay to pass it like the follow on 
 the get/post/head/trace/put method of the test client (max_page_redirect) 
 and make it by default 2 or store it on the settings ?

 def put(self, path, data='', content_type='application/octet-stream',
 follow=False, max_page_redirect=2,
 secure=False, **extra):
 """
 Send a resource to the server using PUT.
 """
 response = super(Client, self).put(path, data=data,
content_type=content_type,
secure=secure, **extra)
 if follow:
 response = self._handle_redirects(response, 
 max_page_redirect,
   **extra)
 return response




-- 
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/2d111040-dd51-499a-8f8d-17a643eae4f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Redirect loop detection in test client is incorrect

[Collin Anderson]

If it helps, I believe Chrome and Firefox have a limit of 20, and Internet 
Explorer have a limit of 10.

On Friday, May 1, 2015 at 2:27:57 PM UTC-4, Mounir Messelmeni wrote:
>
> We've already the max total redirects counts it's 20
>
> if len(redirect_chain) > 20:
> # Such a lengthy chain likely also means a loop, but one with
> # a growing path, changing view, or changing query argument;
> # 20 is the value of "network.http.redirection-limit" from Firefox.
> raise RedirectCycleError("Too many redirects.", last_response=response)
>
>
>
> On Friday, May 1, 2015 at 8:24:48 PM UTC+2, Mounir Messelmeni wrote:
>>
>> I think 10 is already too much, it about redirecting to the same page N 
>> times. Page1 to Page, Page2 to Page3 and Page3 to the Page1: N=2 redirects 
>> to the Page1.
>> Do you think 10 times make senses? In my opinion it's too much and the 
>> need to raise an error to make developers know about something wrong in 
>> their redirects else they can override it for an extreme purpose.
>>
>> On Friday, May 1, 2015 at 7:54:44 PM UTC+2, Tim Graham wrote:
>>>
>>> Is there any disadvantage to making it some "large" number like 10? In 
>>> that case it probably wouldn't need to be configurable. The additional time 
>>> to do 10 loops instead of 2 is probably trivial (and it's an unexpected 
>>> condition anyway).
>>>
>>> On Friday, May 1, 2015 at 1:36:32 PM UTC-4, Mounir Messelmeni wrote:

 This is related to the ticket #24713, I'm trying to fix this issue and 
 I was thinking about using a variable to know how much time a single url 
 can be repeated on the redirects.
 Is two time sufficient or we will have another case that need 3 times.
 If you agree using a variable is it okay to pass it like the follow on 
 the get/post/head/trace/put method of the test client (max_page_redirect) 
 and make it by default 2 or store it on the settings ?

 def put(self, path, data='', content_type='application/octet-stream',
 follow=False, max_page_redirect=2,
 secure=False, **extra):
 """
 Send a resource to the server using PUT.
 """
 response = super(Client, self).put(path, data=data,
content_type=content_type,
secure=secure, **extra)
 if follow:
 response = self._handle_redirects(response, 
 max_page_redirect,
   **extra)
 return response




-- 
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/da3552dc-bd01-4f78-850e-240277fa01d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANNOUNCE] Django bugfix releases issued: 1.8.1 and 1.7.8

[Tim Graham]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2015/may/01/bugfix-releases-issued/

-- 
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/ad207640-a7ce-452e-b61f-a4d9ced57d62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

[Christopher Adams]

Hey guys,

Thanks for the great feedback and replies.

Generally agree with everyone that post-commit hooks shouldn't be strictly 
coupled to the signals framework philosophically speaking.

I disagree with Carl's premise that using `connection.on_commit` in your 
signal handler is simpler than adding `after_commit=True` as a kwarg. It 
involves not only an extra import, but also familiarity by developers with 
the notion of closure and callbacks. Despite being a powerful feature of 
Python, this is not really as familiar a usage pattern among developers as 
adding an additional keyword argument is. I think that having the option to 
add `after_commit=True` to a ModelSignal registration point will be a 
popular addition to Django. I am speaking from the simplicity of the 
Python-API perspective we expose here. And, from experience -- at Venmo we 
see this problem every day and would love a simple binary-flag solution 
like that. I'm assuming many people have ModelSignals that they would love 
to upgrade with a single change like that.

I'm a little confused by what Carl is saying that my branch would require 
two ways of doing the same thing. Carl I don't think this is true; I could 
easily rename my function `add_callback_after_commit` to `on_commit` and 
extend it. As far as I can see, there are more detailed semantics around 
manual commits as well as savepoint commits that your project implements 
that I don't have in my branch. Then again, I don't claim to. I don't see 
the branches as incompatible. The implementation for the signal handler 
syntax I came up with can very easily be upgraded to use the later-merged 
syntax, underneath the hood, when that is merged.

The advantages of merging my branch now are: 1. it's stable, and it works; 
2. it's a small patch, 3. it guarantees we get a fix to the `post_save` 
usage problem into next version of Django, period, regardless of the 
progress of Andreas' branch, 4. It doesn't prevent us from connecting it to 
whatever final syntax we agree on to going forward (Carl's `on_commit()`, 
or whatever), and 5. (now personally speaking), I'd like at least to get 
some credit for driving the idea here, and to get some of this into Django 
commit history ;). I don't need to take the whole pie but it would be great 
to get my commits in *if* the agreement is the kwarg syntax is useful at 
all.

Happy to work with everyone to make more generic post-commit hook happen in 
addition to what I have already done.

Let me know if I have clearance to open a PR? I don't want to jump the gun 
there and open without formal approval. Thanks.

Chris


On Friday, May 1, 2015 at 2:25:43 PM UTC-4, Andreas Pelme wrote:
>
> Hi, 
>
> > On 30 apr 2015, at 18:42, Carl Meyer > 
> wrote: 
> > 
> > transaction-hooks is actually fairly small and understandable too. And I 
> > don't think it's hard to use for this situation, either; you'd just need 
> > to use `connection.on_commit` in your signal handler if you wanted to 
> > delay some action until post-commit. 
> > 
> >> Unless it's going to be super easy to port transaction-hooks over, I 
> >> think it might be nice to get this in and sealed (it's not adding too 
> >> much more complexity). If transaction-hooks would land in core well, 
> >> let's do that. 
> > 
> > I don't think landing transaction-hooks in core for 1.9 would be hard at 
> > all, and no-one has objected to the idea (AFAIK). I (or anyone really) 
> > just need to get around to it. Motivation has been low so far mostly 
> > because it works fine as an external add-on. 
>
>
> I did an initial port of django-transaction-hooks, it was pretty 
> straightforward. All the hard work has already been done. :-) 
>
> Here is the PR: https://github.com/django/django/pull/4593 
>
> The patch is not yet finished (there’s a todo-list at the PR with some 
> missing pieces). Let me know what you think and I’ll be happy to continue 
> working on a proper patch to get it into a merge-able state. 
>
> Cheers, 
> Andreas 
>
>

-- 
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/ec286243-aa44-42c5-9e34-6f781d8694d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

[Christopher Adams]

Hey guys,

Thanks for the great feedback and replies.

Generally agree with everyone that post-commit hooks shouldn't be strictly 
coupled to the signals framework philosophically speaking.

I disagree with Carl's premise that using `connection.on_commit` in your 
signal handler is simpler than adding `after_commit=True` as a kwarg. It 
involves not only an extra import, but also familiarity by developers with 
the notion of closure and callbacks. Despite being a powerful feature of 
Python, this is not really as familiar a usage pattern among developers as 
adding an additional keyword argument is. I think that having the option to 
add `after_commit=True` to a ModelSignal registration point will be a 
popular addition to Django. I am speaking from the simplicity of the 
Python-API perspective we expose here. And, from experience -- at Venmo we 
see this problem every day and would love a simple binary-flag solution 
like that. I'm assuming many people have ModelSignals that they would love 
to upgrade with a single change like that.

I'm a little confused by what Carl is saying that my branch would require 
two ways of doing the same thing. Carl I don't think this is true; I could 
easily rename my function `add_callback_after_commit` to `on_commit` and 
extend it. As far as I can see, there are more detailed semantics around 
manual commits as well as savepoint commits that your project implements 
that I don't have in my branch. Then again, I don't claim to. I don't see 
the branches as incompatible. The implementation for the signal handler 
syntax I came up with can very easily be upgraded to register its own 
callback to `on_commit()` underneath the hood, when that is merged. In 
other words, I think these branches could work together and don't need to 
be seen as alternatives.

The advantages of merging my branch now are: 1. it's stable, and it works; 
2. it's a small patch, 3. it guarantees we get a fix to the `post_save` 
usage problem into next version of Django, period, regardless of the 
progress of Andreas' branch, 4. It doesn't prevent us from connecting it to 
whatever final syntax we agree on to going forward (Carl's `on_commit()`, 
or whatever), and 5. (now personally speaking), I'd like at least to get 
some credit for driving the idea here, and to get some of this into Django 
commit history ;). I don't need to take the whole pie but it would be great 
to get my commits in *if* the agreement is the kwarg syntax is useful at 
all.

Happy to work with everyone to make more generic post-commit hook happen in 
addition to what I have already done.

Let me know if I have clearance to open a PR? I don't want to jump the gun 
there and open without formal approval. Thanks.

Chris

-- 
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/ada2b88e-c46a-4efa-a08b-3746a4ceda85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.