Suggestions for inclusion_tag (and a problem with #5034?)

[Justin Fagnani]

I ran into a problem trying to use inclusgion_tag() in combination
with a template that used the url tag with #5034 applied.

First, #5034, which patches the url tag to use request.urlconf if it's
been set, checks for an instance of RequestContext, rather than the
key 'request'. This could be changed, with the assumption that
context['request'] should always be a request object.

Then, inclusion_tag, unlike the include tag, creates a new context to
pass to template.render(), rather than passing the current context.
You can pass a context_class to inclusiong_tag, but since
RequestContext takes a request, you can't use that.

I wonder why inclusion_tag is different than include in this respect.
Can't the dict returned by the tag function be pushed onto the current
context? That way the template gets the same context class, it behaves
more like the include tag, and the code actually becomes simpler. Is
there some reason I'm not seeing?

Also, is there any chance of #5034 making it into 1.0? I don't know
how many user set request.urlconf via middleware, but that is
documented, and this patch is critical for using url and reverse().

Thanks,
Justin