Re: Template.render(Context) in django 1.10+
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.
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 <mi...@dewhirst.com.au> 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({}))
>>>
Re: Template.render(Context) in django 1.10+
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:
>> 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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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.
Template.render(Context) in django 1.10+
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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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/CAF1M8pfF6Hnd%2BTsWfJANpD0EOaCnYW8JfrYNU7SJ7DNJq%2BxFAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Error dynamically adding a field to a model in Django 1.7
Hi folks My app django-mptt has a function which dynamically adds a field to a model. A common use-case is hierarchical groups: from mptt.models import TreeForeignKey, register > from django.contrib.auth.models import Group > TreeForeignKey(Group, blank=True, null=True).contribute_to_class(Group, > 'parent') > register(Group) This works great until Django 1.7. I've recently added 1.7 to the tox config and now I'm getting errors during the migration process: django.db.utils.OperationalError: no such column: auth_group.parent_id (full traceback here <https://gist.github.com/craigds/b53cf8a8110530436c7a>) Seems the migration system isn't handling the monkey-patched field properly. Does anyone know how to avoid 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5aaf213c-f648-4d3d-818a-c64fe7fedfc1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: memory leak in django 1.5
Just confirming that this fixed the memory leak problem for us. Thanks again :) On Friday, March 22, 2013 3:07:02 PM UTC+13, Craig de Stigter wrote: > > Karen Tracey saves the day! > > Thanks so much, seems likely that's it :) > > Craig de Stigter > > On Friday, March 22, 2013 2:25:04 PM UTC+13, Karen Tracey wrote: >> >> On Thu, Mar 21, 2013 at 9:00 PM, Craig de Stigter <crai...@gmail.com>wrote: >> >>> Hi everyone >>> >>> (cross-posted because this seems relevant to both django-users and >>> developers, and both might have experienced this problem) >>> >>> We've noticed a gradual increase in memory usage for our apache >>> processes since upgrading to django 1.5. >>> >>> Here is a graph <http://i.imgur.com/cBsUx52.png> showing memory usage >>> before and after we upgraded to django 1.5 on our web server. (the upgrade >>> occurs at 12:30 on the graph). >>> >>> I'm hoping someone else has noticed a similar thing and is able to >>> provide some insight. >>> >> >> https://code.djangoproject.com/ticket/19895#comment:6 >> >> notes a memory leak due to a fix that went into 1.5. >> >> The fix was reverted on the 1.5.x branch about two days ago, so one thing >> to try would be to run current 1.5.x branch level rather than released 1.5. >> >> Karen >> > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: memory leak in django 1.5
Karen Tracey saves the day! Thanks so much, seems likely that's it :) Craig de Stigter On Friday, March 22, 2013 2:25:04 PM UTC+13, Karen Tracey wrote: > > On Thu, Mar 21, 2013 at 9:00 PM, Craig de Stigter > <crai...@gmail.com > > wrote: > >> Hi everyone >> >> (cross-posted because this seems relevant to both django-users and >> developers, and both might have experienced this problem) >> >> We've noticed a gradual increase in memory usage for our apache processes >> since upgrading to django 1.5. >> >> Here is a graph <http://i.imgur.com/cBsUx52.png> showing memory usage >> before and after we upgraded to django 1.5 on our web server. (the upgrade >> occurs at 12:30 on the graph). >> >> I'm hoping someone else has noticed a similar thing and is able to >> provide some insight. >> > > https://code.djangoproject.com/ticket/19895#comment:6 > > notes a memory leak due to a fix that went into 1.5. > > The fix was reverted on the 1.5.x branch about two days ago, so one thing > to try would be to run current 1.5.x branch level rather than released 1.5. > > Karen > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: memory leak in django 1.5
Karen Tracey saves the day! Thanks so much, seems likely that's it :) Craig de Stigter On Friday, March 22, 2013 2:25:04 PM UTC+13, Karen Tracey wrote: > > On Thu, Mar 21, 2013 at 9:00 PM, Craig de Stigter > <crai...@gmail.com > > wrote: > >> Hi everyone >> >> (cross-posted because this seems relevant to both django-users and >> developers, and both might have experienced this problem) >> >> We've noticed a gradual increase in memory usage for our apache processes >> since upgrading to django 1.5. >> >> Here is a graph <http://i.imgur.com/cBsUx52.png> showing memory usage >> before and after we upgraded to django 1.5 on our web server. (the upgrade >> occurs at 12:30 on the graph). >> >> I'm hoping someone else has noticed a similar thing and is able to >> provide some insight. >> > > https://code.djangoproject.com/ticket/19895#comment:6 > > notes a memory leak due to a fix that went into 1.5. > > The fix was reverted on the 1.5.x branch about two days ago, so one thing > to try would be to run current 1.5.x branch level rather than released 1.5. > > Karen > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
memory leak in django 1.5
Hi everyone (cross-posted because this seems relevant to both django-users and developers, and both might have experienced this problem) We've noticed a gradual increase in memory usage for our apache processes since upgrading to django 1.5. Here is a graph <http://i.imgur.com/cBsUx52.png> showing memory usage before and after we upgraded to django 1.5 on our web server. (the upgrade occurs at 12:30 on the graph). I'm hoping someone else has noticed a similar thing and is able to provide some insight. I've spent two days trying to track down where the leak might be but so far come up empty. We are using modwsgi on ubuntu lucid. We were previously running a pre-release (November) django 1.5a1 with no problems, so the bug must be somewhere in https://github.com/koordinates/django/compare/31e616521...e4ba16ce7 . Unfortunately that's a big diff. I've been unable to reproduce the bug on a dev server, and I'm not comfortable with doing `git bisect` on our production box ;) I've tried using Dozer to track down the leak but it appears to cause apache to segfault with annoying regularity before finding anything of consequence. Any tips welcome Thanks 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
django-typed-models - sane single-table model inheritance
In May last year I posted this topic<https://groups.google.com/d/topic/django-developers/1LA98LjNz-g/discussion>on django-developers. We wanted a way to do proxy-model inheritance, while preserving the type of each object when it goes in and out of the database. Unable to find anything that did what I wanted, I wrote my own! It was basically finished by June last year but I finally open-sourced it: https://github.com/craigds/django-typed-models Basically you can just define a base model, with database fields, and then inherit from it as much as you want. The inherited models all become proxy models - they only define in-python behavior, they can't define database fields. Everything gets stored in one table, and retrieving objects from the database will result in them having the correct model class. A single queryset of a superclass might result in the retrieval of multiple types of subclasses, all in one query. See the readme on that github link for an example. Please let me know what you think! And file issues if you have some. Cheers Craig de Stigter Koordinates Ltd -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/Ff9H0nAZHbAJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
