Re: MOSS Award to Django

[Asif Saifuddin]

Awesome  awesome !!! awesome!!! :D :D

On Saturday, December 12, 2015 at 12:19:00 AM UTC+6, Andrew Godwin wrote:
>
> Hi everyone,
>
> For those who haven't seen, Mozilla has awarded $150,000 to Django for 
> work on Channels and request/response improvements lifted from REST 
> Framework. More in the blog post here: 
> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
>
> I'll be coordinating this effort for the most part, but we're still 
> working out who to fund and the roadmap for the project, as well as work 
> out how we can pay people for their work on a different scale to the Django 
> Fellowship, so it might take a bit of time!
>
> I'll be back on here with some questions for people to discuss/answer 
> about the channels design at some point soon, but a lot of the basic design 
> is already up at http://channels.readthedocs.org, so take a read over 
> that if you're interested.
>
> What I can say is that my intention is to both bake Channels into the next 
> major release of Django, as well as hopefully release a pluggable app 
> version that will run on 1.8 and 1.9 - I have some plans around how to do 
> that effectively, but they involve hitherto unforged paths around Django 
> and how we package dependencies, so I can't say we'll get there 100%.
>
> Andrew
>

-- 
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/bbeea75a-1026-42f1-9cb4-56be0c8a08b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make template caching a feature of the Django template engine

[Aymeric Augustin]

Hello,

I would suggest to enable the cached template loader by default when DEBUG = 
False and no ‘loaders’ options is specified.

This is technically backwards-incompatible, but:

- people who don’t usually configure it will get a free performance boost in 
production
- people who do will be able to simplify their configurations


Currently many projects have a variant of this awful pattern:

# settings/prod.py

TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'OPTIONS': {
'loaders': [
('django.template.loaders.cached.Loader', [
'django.template.loaders.app_directories.Loader',
]),
],
},
},
]

# settings/dev.py

from .prod import *

TEMPLATES[0]['OPTIONS'].update({
'loaders': [
'django.template.loaders.app_directories.Loader',
],
})

My suggestion makes it possible to remove the configuration of ‘loaders’ and to 
rely only on DIRS and APP_DIRS instead.


Best regards,

-- 
Aymeric.



> On 11 déc. 2015, at 23:38, Tim Graham  wrote:
> 
> I like the functionality this provides, but the API doesn't seem quite right 
> to me -- namely passing configuration for template loaders through OPTIONS.
> 
> Since you mentioned "the weird way of passing arguments to template loaders" 
> and the fact that the locmem loader uses it, I'd pose the question -- is it 
> appropriate to pass the locmem templates_dict in OPTIONS too? If we go down 
> this path for "auto_reload" and "cache_templates" in OPTIONS, where do you 
> draw the line for what template loader configuration can go in there? Any 
> third-party template loader cannot get arbitrary configuration options from 
> OPTIONS without patching Django, so it doesn't seem like this API has a clear 
> separation of concerns.
> 
> On Thursday, November 26, 2015 at 6:50:51 AM UTC-5, Jaap Roes wrote:
> Yes, more or less. Although it's not strictly required to deprecate the 
> cached template loader.
> 
> However if we can deprecate the cached template loader I'd also like to 
> deprecate the weird way of passing arguments to template loaders 
> https://github.com/django/django/blob/master/django/template/engine.py#L116 
> .
>  The issue with that is that the locmem loader also uses it.
> 
> It would also be interesting to look at the possibility to set a cache 
> backend for the template cache, i.e. don't use process memory but memcached 
> instead.
> 
> On Tuesday, November 24, 2015 at 8:32:49 PM UTC+1, Marc Tamlyn wrote:
> So. If I understand correctly, this would deprecate the existing cached 
> template loader, replace it with a more powerful, debug ready version (on by 
> default?). Assuming this is what you mean, I wholeheartedly support this. 
> There's no reason not to be performant by default.
> 
> Marc
> 
> On 23 Nov 2015 2:16 pm, "Jaap Roes" > wrote:
> It’s considered a good practice to enable template caching in Django. It 
> saves on the overhead of loading and parsing templates and turning them into 
> template objects, which can give a nice performance boost when repeatedly 
> rendering the same templates.
> 
> Currently it’s possible to enable template caching by using the cached 
> loader. To do so you’ll need to add the loaders option to the engine settings 
> and set it to a nesting of lists/tuples (I’ll wager no one can get this 
> correct on the first try without first consulting the docs). This makes 
> enabling template caching needlessly hard, and the discoverability of this 
> feature lower than necessary. To this day I run into developers who have 
> worked with Django for years but are unaware of the cached loader.
> 
> One of the downsides of enabling the cached loader is that it will cache 
> templates until the server is reloaded. This makes it ill suited for 
> development. I have, on many occasions, seen developers (including myself) 
> forget to turn off template caching in their local settings, resulting in 
> lost time trying to figure out why their changes are not showing.
> 
> I think Django can, and should do better. The bare minimum is to make 
> template caching a simple toggle option that can be passed to the engine 
> (https://code.djangoproject.com/ticket/25788 
>  / 
> https://github.com/jaap3/django/commit/21e9d3aa0eb0a9d2728f8a35318d49d528f3a60f
>  
> 
>  (an admittedly naive patch)). This way cache_templates could simply mirror 
> DEBUG and (new) projects can have a sane template caching configuration by 
> default.
> 
> It would also be useful to have caching enabled in development so the 
> template loading behaviour is (mostly) the same in development as it is in 
> production.
> 
> One reason for this is that custom template tags need to be thread safe 
> (https://docs.dja

Re: Make template caching a feature of the Django template engine

[Tim Graham]

I like the functionality this provides, but the API doesn't seem quite 
right to me -- namely passing configuration for template loaders through 
OPTIONS.

Since you mentioned "the weird way of passing arguments to template 
loaders" and the fact that the locmem loader uses it, I'd pose the question 
-- is it appropriate to pass the locmem templates_dict in OPTIONS too? If 
we go down this path for "auto_reload" and "cache_templates" in OPTIONS, 
where do you draw the line for what template loader configuration can go in 
there? Any third-party template loader cannot get arbitrary configuration 
options from OPTIONS without patching Django, so it doesn't seem like this 
API has a clear separation of concerns.

On Thursday, November 26, 2015 at 6:50:51 AM UTC-5, Jaap Roes wrote:
>
> Yes, more or less. Although it's not strictly required to deprecate the 
> cached template loader.
>
> However if we can deprecate the cached template loader I'd also like to 
> deprecate the weird way of passing arguments to template loaders 
> https://github.com/django/django/blob/master/django/template/engine.py#L116. 
> The issue with that is that the locmem loader also uses it.
>
> It would also be interesting to look at the possibility to set a cache 
> backend for the template cache, i.e. don't use process memory but memcached 
> instead.
>
> On Tuesday, November 24, 2015 at 8:32:49 PM UTC+1, Marc Tamlyn wrote:
>>
>> So. If I understand correctly, this would deprecate the existing cached 
>> template loader, replace it with a more powerful, debug ready version (on 
>> by default?). Assuming this is what you mean, I wholeheartedly support 
>> this. There's no reason not to be performant by default.
>>
>> Marc
>> On 23 Nov 2015 2:16 pm, "Jaap Roes"  wrote:
>>
>>> It’s considered a good practice to enable template caching in Django. It 
>>> saves on the overhead of loading and parsing templates and turning them 
>>> into template objects, which can give a nice performance boost when 
>>> repeatedly rendering the same templates.
>>>
>>> Currently it’s possible to enable template caching by using the cached 
>>> loader. To do so you’ll need to add the loaders option to the engine 
>>> settings and set it to a nesting of lists/tuples (I’ll wager no one can get 
>>> this correct on the first try without first consulting the docs). This 
>>> makes enabling template caching needlessly hard, and the discoverability of 
>>> this feature lower than necessary. To this day I run into developers who 
>>> have worked with Django for years but are unaware of the cached loader.
>>>
>>> One of the downsides of enabling the cached loader is that it will cache 
>>> templates until the server is reloaded. This makes it ill suited for 
>>> development. I have, on many occasions, seen developers (including myself) 
>>> forget to turn off template caching in their local settings, resulting in 
>>> lost time trying to figure out why their changes are not showing.
>>>
>>> I think Django can, and should do better. The bare minimum is to make 
>>> template caching a simple toggle option that can be passed to the engine (
>>> https://code.djangoproject.com/ticket/25788 / 
>>> https://github.com/jaap3/django/commit/21e9d3aa0eb0a9d2728f8a35318d49d528f3a60f
>>>  
>>> (an admittedly naive patch)). This way cache_templates could simply mirror 
>>> DEBUG and (new) projects can have a sane template caching configuration by 
>>> default.
>>>
>>> It would also be useful to have caching enabled in development so the 
>>> template loading behaviour is (mostly) the same in development as it is in 
>>> production.
>>>
>>> One reason for this is that custom template tags need to be thread safe (
>>> https://docs.djangoproject.com/en/1.8/howto/custom-template-tags/#thread-safety-considerations).
>>>  
>>> Because cached templates always reuse the nodes it’s easier to notice when 
>>> a template tag misbehaves.
>>>
>>> Another reason is that the performance of template rendering will be 
>>> roughly the same development as in production, which can make a great 
>>> difference if you’re working with complex templates and/or custom tags that 
>>> perform expensive operations in their __init__.
>>>
>>> Off course, having caching on in development is impractical if templates 
>>> stay cached forever. So some sort of template invalidation and reloading 
>>> system needs to be added. It’s actually fairly easy to add this to the 
>>> cached loader https://code.djangoproject.com/ticket/25791 / 
>>> https://github.com/jaap3/django/commit/20e1caa9f923d82ce60dff155304de5289242186
>>>  
>>> (an earlier/alternative implementation that moves caching to the engine can 
>>> be found here: 
>>> https://github.com/prestontimmons/django/commit/4683300c60033ba0db472c81244f01ff932c6fb3
>>> ).
>>>
>>> With caching and auto reloading as a core feature of Django’s engine it 
>>> will be (somewhat) on par with the alternative Jinja2 engine shipped by 
>>> Django. Jinja2’s Engine lets you con

MOSS Award to Django

[Andrew Godwin]

Hi everyone,

For those who haven't seen, Mozilla has awarded $150,000 to Django for work
on Channels and request/response improvements lifted from REST Framework.
More in the blog post here:
https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/

I'll be coordinating this effort for the most part, but we're still working
out who to fund and the roadmap for the project, as well as work out how we
can pay people for their work on a different scale to the Django
Fellowship, so it might take a bit of time!

I'll be back on here with some questions for people to discuss/answer about
the channels design at some point soon, but a lot of the basic design is
already up at http://channels.readthedocs.org, so take a read over that if
you're interested.

What I can say is that my intention is to both bake Channels into the next
major release of Django, as well as hopefully release a pluggable app
version that will run on 1.8 and 1.9 - I have some plans around how to do
that effectively, but they involve hitherto unforged paths around Django
and how we package dependencies, so I can't say we'll get there 100%.

Andrew

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1upjXf2LLk2gGA9mzdPQn4DbWehSHNFWhF-GkEk4q54gHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: minify static files (css and js)

[Florian Apolloner]

Please stop spamming this thread with a advertisements for an online 
service. This is completely useless to us.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/53712090-599e-4397-ad20-10f6aa0e8ad9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 'DatabaseWrapper' object has no attribute 'pattern_ops' DJango 1.8.3

[Florian Apolloner]

ibm_db_django is not a supported database backend, please get in contact 
with IBM instead for a fix.

Cheers,
Florian

On Friday, December 11, 2015 at 11:37:29 AM UTC+1, Jose Paul wrote:
>
> Getting the error below when I run DJango test  please let me know the 
> reason behind this .Thanks You
>
> =
> ERROR: test_patterns_escape (expressions.tests.ExpressionsTests)
> --
> Traceback (most recent call last):
>   File 
> "C:\Users\IBM_ADMIN\PythonWorkspace\DJangoTestCases\src\DJangoTestCases\tests\expressions\tests.py",
>  
> line 383, in test_patterns_escape
> ordered=False)
>   File "C:\Python27\lib\site-packages\django\test\testcases.py", line 883, 
> in assertQuerysetEqual
> items = six.moves.map(transform, qs)
>   File "C:\Python27\lib\site-packages\django\db\models\query.py", line 
> 162, in __iter__
> self._fetch_all()
>   File "C:\Python27\lib\site-packages\django\db\models\query.py", line 
> 965, in _fetch_all
> self._result_cache = list(self.iterator())
>   File "C:\Python27\lib\site-packages\django\db\models\query.py", line 
> 238, in iterator
> results = compiler.execute_sql()
>   File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", 
> line 829, in execute_sql
> sql, params = self.as_sql()
>   File 
> "c:\python27\lib\site-packages\ibm_db_django-1.0.7-py2.7.egg\ibm_db_django\compiler.py",
>  
> line 48, in as_sql
> return super( SQLCompiler, self ).as_sql( False, with_col_aliases )
>   File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", 
> line 387, in as_sql
> where, w_params = self.compile(self.query.where)
>   File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", 
> line 357, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "C:\Python27\lib\site-packages\django\db\models\sql\where.py", line 
> 104, in as_sql
> sql, params = compiler.compile(child)
>   File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", 
> line 357, in compile
> sql, params = node.as_sql(self, self.connection)
>   File "C:\Python27\lib\site-packages\django\db\models\lookups.py", line 
> 213, in as_sql
> rhs_sql = self.get_rhs_op(connection, rhs_sql)
>   File "C:\Python27\lib\site-packages\django\db\models\lookups.py", line 
> 325, in get_rhs_op
> pattern = 
> connection.pattern_ops[self.lookup_name].format(connection.pattern_esc)
> AttributeError: 'DatabaseWrapper' object has no attribute 'pattern_ops'
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a424fe6-8f07-428b-9db4-ff1eb0e41dac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: minify static files (css and js)

[buyi wen]

you can try this free online service to compress javascript 
  and minify css 
 , so it will reduce the size 
of web page. only need you upload the static js and css files, then you can 
download the mini file.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6b4ee3f3-5d35-4ca8-9688-21767a56d230%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Split DeleteView into a more generic ConfirmView

[Marc Tamlyn]

No problem - I mentioned this thread on twitter to one of the braces devs
and he also likes your idea.
https://twitter.com/kennethlove/status/674237007439073280

On 10 December 2015 at 23:52, Lennart Buit  wrote:

> Hello Marc,
>
> Thanks for your response, I will change my proposal to target
> django-braces. Will take me a few days tho, because I am loaded with
> (school) work right now :).
>
> --Lennart
>
> On Tuesday, December 8, 2015 at 10:38:01 AM UTC+1, Marc Tamlyn wrote:
>>
>> Hi Lennart,
>>
>> I certainly like the idea and have written at least two implementations
>> of `ConfirmView` in my projects before. Without getting into specifics, I'm
>> not sure how we feel about adding more generic views like this, even where
>> it does make sense. To me a good initial course of action could be to
>> consider integrating it with django-braces. They have a collection of
>> common mixins for common or fairly common CBV patterns. In fact we have
>> already merged commonly used parts of django-braces into contrib.auth for
>> 1.9.
>>
>> Marc
>>
>> On 7 December 2015 at 20:28, Lennart Buit  wrote:
>>
>>> I should add patches that I promise to add ;)
>>>
>>> --Lennart
>>>
>>>
>>> On Monday, December 7, 2015 at 9:23:19 PM UTC+1, Lennart Buit wrote:

 Hey all,

 One of my minor annoyances with the class based view system in django
 is that there is no clear way to model a confirmable action. The concept
 does exists in cbv, but only for deleting objects. I however think that
 there are more usages for confirming actions other then delete.

 Lets look at an example, a news site can CRUD newsaticles. But this
 news site has some articles for free, and some other behind a paywall.
 Also, editors on this site can publish newsarticles (after which they come
 in the pay section), and then promote them to free articles. The views in
 django would then look as follows (with some brevity):

 # This also goes for Update/Delete/...
 class NewsArticleCreateView(CreateView):
 model = NewsArticle

 # This also goes for Promote
 class NewsArticlePublishView(DetailView):
 model = NewsArticle
 success_url = 'somewhere'

 def post(self, *args, **kwargs):
 self.object = self.get_object()
 success_url = self.get_success_url()
 self.object.published = True
 self.object.save()

 return HttpResponseRedirect(success_url)

 def get_success_url(self):
 if self.success_url:
 return self.success_url.format(**self.object.__dict__)
 else:
 raise ImproperlyConfigured(
 "No URL to redirect to. Provide a success_url.")

 The problem, I think, is that we are copying most of a DeleteView for a
 fairly standard confirmable action. The get_success_url function is almost
 the same, and most of the code found in the post function is that of delete
 in DeleteView. I think therefore that we should consider splitting the
 DeleteMixin in a more generic ConfirmMixin, make DeleteMixin a subclass of
 ConfirmMixin, and introduce the (more) generic BaseConfirmView and
 ConfirmView. The above example will then look as follows:

 class NewsArticlePublishView(ConfirmView):
 model = NewsArticle
 success_url = 'somewhere'

 def action_confirmed(self):
 self.object.published = True
 self.object.save()

 I think the benefits of this solution are clear, we introduce
 readability in these types of views (look at the class declaration, its a
 confirm view alright!) at the cost of library size (another 3 classes got
 added).

 Please be gentle, I am new here ;). But, I enjoy a technical
 discussion! And I attached a patch that implement this proposal, it however
 should be treated as a POC, not a complete implementation with tests and
 docs and such.

 --Lennart

>>> --
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/16df2f54-fee9-4b5d-9882-bc9954a5c8dd%40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You receive

Mozilla Open Source Support: Django: $150,000.

[CHI Cheng]

>
> Django is a popular server-side Web development framework, used in many 
> Mozilla websites. Their award will be used to make Django suitable to be a 
> back end for Web apps which use WebSockets.
>

 
https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source-support-first-awards-made/

Congratulations to the great team.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/29f42958-9741-4f0e-8695-fc886e1f694c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

'DatabaseWrapper' object has no attribute 'pattern_ops' DJango 1.8.3

[Jose Paul]

Getting the error below when I run DJango test  please let me know the 
reason behind this .Thanks You

=
ERROR: test_patterns_escape (expressions.tests.ExpressionsTests)
--
Traceback (most recent call last):
  File 
"C:\Users\IBM_ADMIN\PythonWorkspace\DJangoTestCases\src\DJangoTestCases\tests\expressions\tests.py",
 
line 383, in test_patterns_escape
ordered=False)
  File "C:\Python27\lib\site-packages\django\test\testcases.py", line 883, 
in assertQuerysetEqual
items = six.moves.map(transform, qs)
  File "C:\Python27\lib\site-packages\django\db\models\query.py", line 162, 
in __iter__
self._fetch_all()
  File "C:\Python27\lib\site-packages\django\db\models\query.py", line 965, 
in _fetch_all
self._result_cache = list(self.iterator())
  File "C:\Python27\lib\site-packages\django\db\models\query.py", line 238, 
in iterator
results = compiler.execute_sql()
  File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", 
line 829, in execute_sql
sql, params = self.as_sql()
  File 
"c:\python27\lib\site-packages\ibm_db_django-1.0.7-py2.7.egg\ibm_db_django\compiler.py",
 
line 48, in as_sql
return super( SQLCompiler, self ).as_sql( False, with_col_aliases )
  File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", 
line 387, in as_sql
where, w_params = self.compile(self.query.where)
  File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", 
line 357, in compile
sql, params = node.as_sql(self, self.connection)
  File "C:\Python27\lib\site-packages\django\db\models\sql\where.py", line 
104, in as_sql
sql, params = compiler.compile(child)
  File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", 
line 357, in compile
sql, params = node.as_sql(self, self.connection)
  File "C:\Python27\lib\site-packages\django\db\models\lookups.py", line 
213, in as_sql
rhs_sql = self.get_rhs_op(connection, rhs_sql)
  File "C:\Python27\lib\site-packages\django\db\models\lookups.py", line 
325, in get_rhs_op
pattern = 
connection.pattern_ops[self.lookup_name].format(connection.pattern_esc)
AttributeError: 'DatabaseWrapper' object has no attribute 'pattern_ops'

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/98d90f07-7f12-45d3-9f5d-d017f73ae786%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django template modules compiled with cython

[Florian Apolloner]

Hi Alexandru,

On Thursday, December 10, 2015 at 12:52:46 PM UTC+1, Alexandru Damian wrote:
>
> I cProfile-instrumented *def get_response() *in *django/core/handlers/base.py 
>  
> *without (vanilla django) and with cemplate, posted the results here:
>
> https://github.com/ddalex/django-cemplate/tree/master/profile_data
>

The results are odd, looks as if you are running in a "test"-like 
environment. Please make sure you run them with DEBUG=False and without any 
test instrumentation to mimic a production environment.

Both profiles are with all caches primed. Please compare time spent in 
> django/template/base.py in vanilla (0.773 seconds) and cemplate (0.288) 
> seconds.
>

Yeah, that is roughly a 100% speedup in template rendering (does one say 
100% if twice as fast?!)
 

> Can you please advise on how to continue this work ? 
>> I feel that maintaining separate trees for each Django release is not 
>> scalable on my part.
>>
>  
>> It’s difficult to say without knowing what you’re proposing. Is there 
>> some change you’d like to see merged into Django? Some API hook that you’d 
>> like to add to make your life easier?
>>
>
I am not really convinced that replacing the whole file is a good idea. In 
my experience one gets better results when using Cython by strategically 
replacing single functions and rewriting those in C directly. A factor of 
two is all nice an well, but if this is still just 10% in the overall 
response there might be other (better) optimizations out there.

Cheers,
Florian

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/83250b7f-58fb-46b1-83fe-79b792eb70df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.