Template.render(Context) in django 1.10+

[Craig de Stigter]

Hi folks

I'm upgrading a large app from 1.8 to 1.11 and coming up against this as I traverse through django 1.9:

>>> from django.template import engines, Context

... t = engines['django'].from_string('')

... t.render(Context({}))

...

/path/to/bin/django-admin.py:3: RemovedInDjango110Warning: render() must be called with a dict, not a Context.

This is a surprising warning to me, since the docs still document the use of Template.render(Context) in 2.0: https://docs.djangoproject.com/en/2.0/ref/templates/api/#rendering-a-context

Would someone mind explaining this?

Cheers

Craig de Stigter

[Daniel Roseman]

Not the same thing. `t` here is an instance of django.template.backends.django.Template, whose render method takes a dict. If you did:

  from django.templates import Template

  t = Template('')

then you would have an instance of django.template.base.Template, whose render method takes a context.

I have no idea why the distinction, though.

-- 

DR. 

[Craig de Stigter]

Thanks for the reply.

So I guess there are actually now two types of templates, and they have incompatible API. Neither is deprecated.

Has this confused anyone else? Is this a desirable/necessary situation?

I think in order to have consistent template usage in our project we really need to just use the new-style templates, which means we have to avoid using `django.template.Template` at all. Perhaps it could be deprecated and removed?

Cheers
Craig de Stigter

[Mike Dewhirst]

On 13/03/2018 11:44 AM, Craig de Stigter wrote:

Thanks for the reply.

So I guess there are actually now two types of templates, and they have incompatible API. Neither is deprecated.

Craig

I don't think your guess is correct. Or at least I'm missing something if it is!

I remember bringing a project from 1.8 to 1.11 without any problems other my own mis-readings of the docs. Things changed in 1.9 and the following comes from ... https://docs.djangoproject.com/en/1.9/ref/templates/api/#rendering-a-context. Notice the Deprecated comment  ...

Rendering a context¶

Once you have a compiled Template object, you can render a context with it. You can reuse the same template to render it several times with different contexts.

class Context(dict_=None, current_app=_current_app_undefined)[source]¶

This class lives at django.template.Context. The constructor takes two optional arguments:

• A dictionary mapping variable names to variable values.

• The name of the current application. This application name is used to help resolve namespaced URLs. If you’re not using namespaced URLs, you can ignore this argument.

  Deprecated since version 1.8: The current_app argument is deprecated. If you need it, you must now use a RequestContext instead of a Context.

If you visit the link you quoted (below) and adjust the version part of it and travel back in time you can see there is no change until you get back to 1.9 from which I copied the above section.

Hth

Mike

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/aa356ec2-51d4-45d7-99a3-79ef14c775a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Craig de Stigter]

Cheers Mike

That deprecation notice says to me that Context itself is not deprecated, but the `current_app` argument is. I don't think that's a problem for us as I don't think we've ever used it.

Perhaps I can clarify. As far as I can tell, according to the errors and deprecation warnings I'm receiving in Django 1.9:

• `django.templates.base.Template.render()` requires a Context instance, and does not accept a dict
  
• `django.templates.backends.django.Template.render()` requires a dict, and does not accept a Context instance.
  

While I haven't yet made things 'work' in 1.10 to a point where I can test it adequately, the 1.10 code I've read looks consistent with that hypothesis.

So it really seems there's no clear safe choice, except to absolutely enforce that all templates in my codebase must be one or the other (presumably, the new-style one).

Unfortunately it's really unclear which of the two template classes I'm using in the hundreds of places we render templates in this rather large codebase. The shortcut functions (`render` etc) appear to use the backend-specific template, whereas if I just import Template directly and instantiate it it turns out to be the old-style template.

I'm not really sure what I'm saying except that maybe the old-style Template class just needs to be removed to avoid confusion.

[Mike Dewhirst]

On 13/03/2018 4:55 PM, Craig de Stigter wrote:
> Cheers Mike
>
> That deprecation notice says to me that Context itself is not
> deprecated, but the `current_app` argument is. I don't think that's a
> problem for us as I don't think we've ever used it.
>
> Perhaps I can clarify. As far as I can tell, according to the errors
> and deprecation warnings I'm receiving in Django 1.9:
>

> * `django.templates.base.Template.render()` requires a Context
> instance
> <https://github.com/django/django/blob/stable/1.8.x/django/template/base.py#L206>,

> and does not accept a dict

> * `django.templates.backends.django.Template.render()` /requires a
> dict
> <https://github.com/django/django/blob/stable/1.8.x/django/template/backends/django.py#L55-L70>,
> /and does not accept//a Context instance.
>

It is all news to me so I went looking. If you look at
django/template/__init__.py there seems to be a brief explanation. It
does start by saying the Django template namespace contains two
independent subsystems. One is for pluggable (and the Django template
language is pluggable) template backends. That's probably where the
Jinja template system plugs in. The other subsytem is the Django
template language itself.

I think the answer to your problem might be found in the imports in that
__init__.py

If you are *only* using the Django template system that enormous
codebase probably needs to be adjusted so it does all its
template-oriented imports from that file. In other words ...

from django.template import Template, Context, RequestContext and
whatever else you use.

Again, if you are only using Django templates you should be able to
safely drop imports from 'backend' in favour of the above 'from
django.template import ...'

Hope that works! Don't know of course but I reckon it would be worth a try.

Good luck

Mike

> <https://docs.djangoproject.com/en/1.9/ref/templates/api/#rendering-a-context>

>
> Once you have a compiled |Template|

> <https://docs.djangoproject.com/en/1.9/ref/templates/api/#django.template.Template>

> object, you can render a context with it. You can reuse the same
> template to render it several times with different contexts.
>

> /class /|Context|(/dict_=None/,
> /current_app=_current_app_undefined/)[source]
> <https://docs.djangoproject.com/en/1.9/_modules/django/template/context/#Context>¶
> <https://docs.djangoproject.com/en/1.9/ref/templates/api/#django.template.Context>
>
> This class lives at |django.template.Context|. The constructor
> takes two optional arguments:
>
> *

>
> A dictionary mapping variable names to variable values.
>

> *

>
> The name of the current application. This application name
> is used to help resolve namespaced URLs

> <https://docs.djangoproject.com/en/1.9/topics/http/urls/#topics-http-reversing-url-namespaces>.

> If you’re not using namespaced URLs, you can ignore this
> argument.
>
> Deprecated since version 1.8: The |current_app| argument
> is deprecated. If you need it, you must now use a
> |RequestContext|

> <https://docs.djangoproject.com/en/1.9/ref/templates/api/#django.template.RequestContext>
> instead of a |Context|
> <https://docs.djangoproject.com/en/1.9/ref/templates/api/#django.template.Context>.

>> <mailto:django-users...@googlegroups.com>.

>>
>> To post to this group, send email to

>> django...@googlegroups.com <mailto:django...@googlegroups.com>.

>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/aa356ec2-51d4-45d7-99a3-79ef14c775a5%40googlegroups.com

>> <https://groups.google.com/d/msgid/django-users/aa356ec2-51d4-45d7-99a3-79ef14c775a5%40googlegroups.com?utm_medium=email&utm_source=footer>.

[James Bennett]

On Mon, Mar 12, 2018 at 5:44 PM, Craig de Stigter <craig.d...@koordinates.com> wrote:

Thanks for the reply.

So I guess there are actually now two types of templates, and they have incompatible API. Neither is deprecated.

Has this confused anyone else? Is this a desirable/necessary situation?

Here is what happened:

Django originally shipped with one template language, and that was the

only thing its template framework understood. The interface for it

involved instances of django.template.Template and rendered them using

instances of django.template.Context.

When Django grew support for using multiple template languages, this

became a problem since Django's original template language was the

only one that understood the Django Context object. So the

engine-based interface wants you to pass in a dict instead of a

Context for rendering, which then lets the underlying template

framework figure out what template-language-specific type of object to

convert it into. If you happen to use the original Django template

language, of course it gets converted into a Context instance, but

Django has no way of knowing in advance that this will happen.

The old django.template.Template/django.template.Context interface

hasn't been deprecated, because for users who use only the original

Django template language, it still works and is still a very

convenient and simple API, and there's no need to make them deal with

the indirection of working through the template-engine API. The only

time you need to know or care about the engine API and using plain

dicts is when you start using some other template language with

Django, so the complexity of dealing with the engine API gets deferred

to that point.

The problem you're running into, of course, is an old codebase where

apparently some developers used one of these APIs while some

developers used the other API. And the solution is to pick one and

force the developers on your team to use only that API going forward.

If you know that you are always going to use the original Django

template language, and not use any other language (like Jinja), then

using django.template.Template/django.template.Context is still fine

and is still supported. If you think there's even a small chance that

at some point in the future you might want a different template

language, use the engine API.

Also, it's generally best to avoid from_string(); while it may seem

convenient, it can cause situations where you have template code

hidden somewhere other than where you store your templates. Just make

a real template and use the loader to go find it. And importing

through django.template.base instead of just through django.template

is probably a bad idea; I don't think we have any kind of

compatibility guarantee for django.template.base to keep working,

while we do have one for django.template to keep working. This is why

it's good to use the import path given in the Django documentation,

rather than trying to track down the "real" location of a definition

and import from there instead.