Re: APPEND_SLASH behavior

[chris.j...@gmail.com]

On Thursday, May 6, 2021 at 10:32:59 AM UTC-7 f.apo...@gmail.com wrote:

> I took a quick glance (literally just that) at the pull requests. I do 
> like the one that offers a way to abort early inside a prefix -- this is a 
> nice optimization and as well might open interesting options for 
> specialized catch all views. I am not convinced about the backtracking PR, 
> which problems does this solve in reality? What does this mean for features 
> like atomic requests -- it is still just one request after all…
>

I'm the one that filed the "abort early" ticket. I was curious about the 
other one though after reading some of the discussion. With the suggested 
work-around of having a view call other views, would a view be able to 
continue URL resolution in that case? To avoid the problems with the bad 
interaction with the request machinery, another approach that came to mind 
would be to allow inserting / including a function at any point in the 
URLconf. The function would return whether the pattern should be skipped or 
claimed. That would have the advantage of taking place before any view is 
started.

--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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/941a7a20-e5a4-4450-a9e8-1871e2fb1c91n%40googlegroups.com.

Re: APPEND_SLASH behavior

[Florian Apolloner]

On Thursday, May 6, 2021 at 10:19:42 PM UTC+2 Adam Johnson wrote:

> That said, I think doing this in process_response would be preferable over 
>> doing it in process_request so the extra checks when the URL is valid (the 
>> common case) are reduced. Resolving URLs can take a bit, especially when 
>> the urlconf is long and as such I'd like to get that check out of the "hot" 
>> code path. Only doing the redirect in the case of a failing resolve in the 
>> first place would probably make this more efficient.
>
>
> I agree. I guess it might need a deprecation cycle to move it to 
> process_response though?
>

Maybe, maybe not. It already (partially?) does exist in process_response as 
well. If we can show that this doesn't break existing stuff we can do 
without deprecation.

-- 
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/e0fc2fa7-2b94-41f1-8136-cf8fa2e15bc7n%40googlegroups.com.

Re: APPEND_SLASH behavior

[Florian Apolloner]

Hi Chris,

nice hearing from you.

On Friday, May 7, 2021 at 6:20:44 PM UTC+2 chris.j...@gmail.com wrote:

> With the suggested work-around of having a view call other views, would a 
> view be able to continue URL resolution in that case? 
>

Not without many code changes I fear and I am not sure about the gains.
 

> To avoid the problems with the bad interaction with the request machinery, 
> another approach that came to mind would be to allow inserting / including 
> a function at any point in the URLconf. The function would return whether 
> the pattern should be skipped or claimed. That would have the advantage of 
> taking place before any view is started.
>

I'll put it like this: Interesting idea but I am afraid of the outcome :D 
Before I'd support such a change we'd really want to gather usecases first 
and think hard what it could/would break… And now I cannot stop thinking 
about such a function ala "lambda: random.choice([True, False])". Thank you 
for that ;)

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0c72e667-0223-4a28-8e4f-83c5d0f3c758n%40googlegroups.com.

Re: APPEND_SLASH behavior

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

>
> To avoid the problems with the bad interaction with the request machinery,
> another approach that came to mind would be to allow inserting / including
> a function at any point in the URLconf. The function would return whether
> the pattern should be skipped or claimed. That would have the advantage of
> taking place before any view is started.


One can already do this by reaching a little into the internals... but I'm
also not sure it's a good idea.

You can do it like so:

from functools import partial

from django.urls.conf import _path
from django.urls.resolvers import RoutePattern


class FilteringRoutePattern(RoutePattern):
def match(self, path):
matched = super().match(path)
if matched and my_other_logic():
matched = None
return matched

filtering_path = partial(_path, Pattern=FilteringRoutePattern)

I tried it with my_other_logic() doing random.choice([True, False]) and it
works.

On Fri, 7 May 2021 at 17:48, Florian Apolloner 
wrote:

> Hi Chris,
>
> nice hearing from you.
>
> On Friday, May 7, 2021 at 6:20:44 PM UTC+2 chris.j...@gmail.com wrote:
>
>> With the suggested work-around of having a view call other views, would a
>> view be able to continue URL resolution in that case?
>>
>
> Not without many code changes I fear and I am not sure about the gains.
>
>
>> To avoid the problems with the bad interaction with the request
>> machinery, another approach that came to mind would be to allow inserting /
>> including a function at any point in the URLconf. The function would return
>> whether the pattern should be skipped or claimed. That would have the
>> advantage of taking place before any view is started.
>>
>
> I'll put it like this: Interesting idea but I am afraid of the outcome :D
> Before I'd support such a change we'd really want to gather usecases first
> and think hard what it could/would break… And now I cannot stop thinking
> about such a function ala "lambda: random.choice([True, False])". Thank you
> for that ;)
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0c72e667-0223-4a28-8e4f-83c5d0f3c758n%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/CAMyDDM3uuhf%3DSDyYObZptzXZ%3D1fgKAWp1kV2UifBV3QpJdwdtQ%40mail.gmail.com.