Given we already have `request.build_absolute_uri(path)`, I'm not 100% sure what extra this gives us. It's a bit of syntactic sugar for sure, but it solves a pretty narrow use case. The only times I've actually needed this has been when sending emails and I'm using a `Site` object instead of request.
In a way, this fits in with the work on a new URL resolving system, especially if like the "URL" resolution in channels it can take other attributes of the request. This would make things like Django hosts easier to build, as well as nice things like resolution based on URL scheme. If we go down that route, then it makes sense for `reverse` to take kwargs like `host` or `scheme` as it may be needed to work out which route to use anyway. I'm definitely -1 on a threadlocal request. Marc On 11 November 2016 at 08:14, Mislav Cimperšak <mislav.cimper...@gmail.com> wrote: > Thinking about url tag and threadlocals is a step in the wrong direction. > > The original PR is just a simple addition (that is still backwards > compatible) to the `reverse` method; how people choose to use it (and when) > is up to them. Adding something to the `url` tag is almost bound to brake > something. > This implementation does not brake anything regarding `url` tag and can > stand on it's own. > > I've talked to several people on sprints in Amsterdam before submitting a > PR and it sounded like a good idea to them and reassured with DRF > implementation I went with it :) > > On Sat, Nov 5, 2016 at 11:04 PM, Florian Apolloner <f.apollo...@gmail.com> > wrote: > >> On Saturday, November 5, 2016 at 6:56:29 PM UTC+1, Sjoerd Job Postmus >> wrote: >>> >>> If you go with storing the base domain in the threadlocals, why not go >>> full in and store the request itself in the locals? [1] >>> >> >> Because that opens a whole new can of worms, if possible we want less >> threadlocals, not more… >> >> >>> As far as using it in the templates... We have a RequestContext right? >>> So in most cases that should not be an issue I presume. >>> >> >> Still leaves the question of how to nicely pass this to the url tag. >> >> But yes, Celery would be a problem, unless we push the request object to >>> celery as well, but I presume that makes mostly no sense except for this. >>> >> >> Yeah, I didn't think that through :) >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/django-developers/-rbLcdJkIpk/unsubscribe. >> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/django-developers. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/django-developers/84fc3b7a-4263-46bb-a292-e27215952e63% >> 40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/84fc3b7a-4263-46bb-a292-e27215952e63%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> 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 https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/CACcAD09g-yCWw6U5WS-ykKJRG5poWnrBCEOTGFO6YrQKgCKeP > Q%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CACcAD09g-yCWw6U5WS-ykKJRG5poWnrBCEOTGFO6YrQKgCKePQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1EBwxMsmmqW1gikndx8B%3DZep6AeWDEmmF3koMDpH83BMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
