Template.render(Context) in django 1.10+

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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


--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAF1M8pfF6Hnd%2BTsWfJANpD0EOaCnYW8JfrYNU7SJ7DNJq%2BxFAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Template.render(Context) in django 1.10+

Daniel Roseman-2
On Sunday, 11 March 2018 21:06:51 UTC, Craig de Stigter wrote:
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: <a href="https://docs.djangoproject.com/en/2.0/ref/templates/api/#rendering-a-context" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Fref%2Ftemplates%2Fapi%2F%23rendering-a-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaMdSSf-KL4csCYcqnkZ7BPPIlEw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Fref%2Ftemplates%2Fapi%2F%23rendering-a-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaMdSSf-KL4csCYcqnkZ7BPPIlEw&#39;;return true;">https://docs.djangoproject.com/en/2.0/ref/templates/api/#rendering-a-context

Would someone mind explaining this?

Cheers
Craig de Stigter



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. 

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/a6f7857a-a32e-4c13-8db7-e85bfcedad73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Template.render(Context) in django 1.10+

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

On Monday, 12 March 2018 11:21:41 UTC+13, Daniel Roseman wrote:
On Sunday, 11 March 2018 21:06:51 UTC, Craig de Stigter wrote:
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: <a href="https://docs.djangoproject.com/en/2.0/ref/templates/api/#rendering-a-context" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Fref%2Ftemplates%2Fapi%2F%23rendering-a-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaMdSSf-KL4csCYcqnkZ7BPPIlEw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Fref%2Ftemplates%2Fapi%2F%23rendering-a-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaMdSSf-KL4csCYcqnkZ7BPPIlEw&#39;;return true;">https://docs.djangoproject.com/en/2.0/ref/templates/api/#rendering-a-context

Would someone mind explaining this?

Cheers
Craig de Stigter



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. 

--
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Template.render(Context) in django 1.10+

Mike Dewhirst-3
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


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

On Monday, 12 March 2018 11:21:41 UTC+13, Daniel Roseman wrote:
On Sunday, 11 March 2018 21:06:51 UTC, Craig de Stigter wrote:
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: <a href="https://docs.djangoproject.com/en/2.0/ref/templates/api/#rendering-a-context" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Fref%2Ftemplates%2Fapi%2F%23rendering-a-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaMdSSf-KL4csCYcqnkZ7BPPIlEw';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Fref%2Ftemplates%2Fapi%2F%23rendering-a-context\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaMdSSf-KL4csCYcqnkZ7BPPIlEw';return true;" moz-do-not-send="true">https://docs.djangoproject.com/en/2.0/ref/templates/api/#rendering-a-context

Would someone mind explaining this?

Cheers
Craig de Stigter



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. 
--
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 [hidden email].
To post to this group, send email to [hidden email].
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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/dfef1fa0-92a7-0147-2e83-72e5050e3203%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Template.render(Context) in django 1.10+

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:
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.


On Tue, 13 Mar 2018 at 14:50 Mike Dewhirst <[hidden email]> wrote:
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


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

On Monday, 12 March 2018 11:21:41 UTC+13, Daniel Roseman wrote:
On Sunday, 11 March 2018 21:06:51 UTC, Craig de Stigter wrote:
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



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. 
--
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 [hidden email].

To post to this group, send email to [hidden email].
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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAF1M8pf4ofA9F_7iqpRbcY2Z-cYOvRDhFezprwWSofPyd%2B-gYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Template.render(Context) in django 1.10+

Mike Dewhirst-3
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

> 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.
>
>
> On Tue, 13 Mar 2018 at 14:50 Mike Dewhirst <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     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¶
>         <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>.
>
>
>     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
>
>>
>>     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
>>
>>     On Monday, 12 March 2018 11:21:41 UTC+13, Daniel Roseman wrote:
>>
>>         On Sunday, 11 March 2018 21:06:51 UTC, Craig de Stigter wrote:
>>
>>             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
>>
>>
>>
>>         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.
>>
>>     --
>>     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 [hidden email]
>>     <mailto:[hidden email]>.
>>
>>     To post to this group, send email to
>>     [hidden email] <mailto:[hidden email]>.
>>     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>.
>>     For more options, visit https://groups.google.com/d/optout.
>

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/0ea1022c-e596-56c3-93ed-56d72ef9a6c7%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Template.render(Context) in django 1.10+

James Bennett
In reply to this post by Craig de Stigter
On Mon, Mar 12, 2018 at 5:44 PM, Craig de Stigter <[hidden email]> 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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAL13Cg_Fx9R012t9KKDEQ8LajJNOpbXGRUyNR9%2BYXkMBZXzzCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.