#35985: SCRIPT_NAME / FORCE_SCRIPT_NAME ignored when running reverse() on 
non-main
thread
-------------------------------------+-------------------------------------
     Reporter:  Pēteris Caune        |                    Owner:  (none)
         Type:                       |                   Status:  closed
  Cleanup/optimization               |
    Component:  Core (URLs)          |                  Version:  dev
     Severity:  Normal               |               Resolution:  wontfix
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Natalia Bidart):

 * cc: Florian Apolloner (added)
 * resolution:   => wontfix
 * status:  new => closed
 * type:  Bug => Cleanup/optimization
 * version:  5.1 => dev

Comment:

 Hello Pēteris Caune, thank you for taking the time to create this report.
 I have read your description carefully and I yes, I agree, the fact that
 `_prefixes` is local to the thread means that spawned threads will not
 share its contents. Also the function `set_script_prefix` has this
 docstring:

 > Set the script prefix for the current thread.

 For a workaround, Django will set the prefix when `setup` is called,
 perhaps the best option for your management command is to call `setup` in
 each thread? Feels cleaner and more correct.

 Regarding your comment for ''change django.urls implementation so that
 threads do share the script prefix storage'', in my opinion this is beyond
 to what the main goal of Django is. As shown above, this is simple to
 add/solve to your code base, and to me this is a very specific need
 arising from a niche use case. I don't think this applies to the broader
 ecosystem, and Django is a framework designed to offer robust and accurate
 solutions for common scenarios.

 Given the above, I'll close the ticket accordingly, but if you disagree,
 you can consider starting a new conversation on the
 [https://forum.djangoproject.com/c/internals/5 Django Forum], where you'll
 reach a wider audience and likely get extra feedback.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/35985#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/01070193abcb6138-08828b1b-8044-4f5f-8236-a16fe6d20474-000000%40eu-central-1.amazonses.com.

Reply via email to