Hey Curtis,
I was working to remove origin.reload and ended up with a fork that
combines the debug implementation:
https://github.com/django/django/pull/4254
On a complex template with debug off I'm measuring about a 5% increase in
template compile time compared to master. Turning debug on add
Just to chip in here... when TEMPLATE_DEBUG=True the template engine uses a
substantially different Lexer, based on re.finditer() instead of re.split().
There are about 10 hooks in the Parser class, too, that exist almost
exclusively to allow the DebugParser to change behavior.
If we always store
Here are some benchmarks I added here:
https://github.com/prestontimmons/templatebench
This is the cumulative time to do 1000 iterations:
Basic.do_init: 0.1423451900
BasicDebug.do_init: 0.1941769123
35% increase in parsing time
Basic.do_parse_complex: 1.2230978012
BasicDebug.do_parse_complex: 1
Just to clear a possible confusion — that will still be possible, but you’ll
have to do it differently once you start using the TEMPLATES setting:
DEBUG = True
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'OPTIONS': {
# ...
Sometimes I had to enable DEBUG and disable TEMPLATE_DEBUG in order to
get useful information about a crash. Am I the only one ?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this grou
+1,
Thanks,
On 02/15/2015 03:15 PM, Aymeric Augustin wrote:
Hello,
During the multiple template engines refactor, I didn’t touch
TEMPLATE_DEBUG.
The only purpose of this setting is to control whether Django stores the
information required to display stack traces for exceptions that occur
wh
2015-02-16 14:30 GMT+01:00 Collin Anderson :
> Is there a reason to not always store the debug information? Performance?
> Why have two behaviors?
>
Yes, I assume performance was the reason when this code was written, around
2005 or 2006.
I can't say if performance is still a concern after 10 ye
Hi,
Is there a reason to not always store the debug information? Performance?
Why have two behaviors?
Thanks,
Collin
On Sun, Feb 15, 2015 at 9:15 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> During the multiple template engines refactor, I didn’t touch
> TEMPL
+1!
On Sunday, February 15, 2015 at 2:16:25 PM UTC, Aymeric Augustin wrote:
>
> Hello,
>
> During the multiple template engines refactor, I didn’t touch
> TEMPLATE_DEBUG.
> The only purpose of this setting is to control whether Django stores the
> information required to display stack traces for
+1
Last year I do an app to develop templates on the fly granting template_debug
dump to some users (designers) and even in that escenario is looking good. Go
for it.
On Sun, Feb 15, 2015 at 4:42 PM, Marc Tamlyn
wrote:
> +1 to removing it
> On 15 Feb 2015 14:16, "Aymeric Augustin"
> wrote:
>
+1, sounds logical to me.
On Sun, Feb 15, 2015 at 4:42 PM, Marc Tamlyn wrote:
> +1 to removing it
> On 15 Feb 2015 14:16, "Aymeric Augustin" <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hello,
>>
>> During the multiple template engines refactor, I didn’t touch
>> TEMPLATE_DEBUG.
>> The on
+1 to removing it
On 15 Feb 2015 14:16, "Aymeric Augustin"
wrote:
> Hello,
>
> During the multiple template engines refactor, I didn’t touch
> TEMPLATE_DEBUG.
> The only purpose of this setting is to control whether Django stores the
> information required to display stack traces for exceptions t
Hello,
During the multiple template engines refactor, I didn’t touch TEMPLATE_DEBUG.
The only purpose of this setting is to control whether Django stores the
information required to display stack traces for exceptions that occur while
rendering Django templatse. I think I should have deprecated it
13 matches
Mail list logo
