Re: Drop the TEMPLATE_DEBUG setting

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:

Re: Formalizing template loader and debug api's

Hi Aymeric, I'm thinking of proposing an alternative to the cached loader. This new approach makes Django faster in general. To start, I put together some benchmarks here: https://github.com/prestontimmons/templatebench The goal was to identify where Django spends it's time. Is it the loaders

Re: JsonResponse and list values

My attempts to reproduce it (I have quite a lot of code that returns JSON arrays) on the smattering of browsers I had handy resulted in no apparent vulnerabilities. On Tuesday, February 17, 2015 at 10:30:20 AM UTC+10:30, Tom Christie wrote: > > I haven't dug out sources on this, but I think

Re: Psycopg2 version support

On Mon, Feb 16, 2015 at 1:41 PM, Thomas Stephenson wrote: > And now I'll shut up, because I'm not entitled to an opinion here yet :D > By the way, Thomas, your opinion is welcome. :) Collin -- You received this message because you are subscribed to the Google Groups

Re: status of 1.8 release blockers

Here's the status on blockers. Given the work that remains, I don't foresee the beta release happening earlier than Wednesday, but the next update of this thread will be tomorrow. #24324 Crashes when project path or path to Django install contains

Re: JsonResponse and list values

I haven't dug out sources on this, but I think that vulnerability had been dealt with a long time ago, and isn't an issue on browsers with any real market share today. Would need to double check though - don't remember where I came across it previously. -- You received this message because

Re: JsonResponse and list values

Cheers for the quick reply... well, you learn more about how shit JS is every day :P -- C On 17 February 2015 at 10:41, Florian Apolloner wrote: > > > On Tuesday, February 17, 2015 at 12:30:25 AM UTC+1, Curtis Maloney wrote: >> >> Ran into this bug this morning... what's

Re: JsonResponse and list values

On Tuesday, February 17, 2015 at 12:30:25 AM UTC+1, Curtis Maloney wrote: > > Ran into this bug this morning... what's the rationale behind JsonResponse > only accepting dict types unless you set safe=False to allow _any_ type? > Cause dict maps to object which is somewhat safe. > Surely

JsonResponse and list values

Ran into this bug this morning... what's the rationale behind JsonResponse only accepting dict types unless you set safe=False to allow _any_ type? Surely list/tuple should also be permitted? There's a test explicitly ensuring lists fail. I'm not comfortable turning off ALL type safe-guards

Re: Psycopg2 version support

ps. 2.4.5 is the real minimum. The db.backends module loads without error at 2.4.3, but proper support for Inet arrays was not added until 2.4.5, so any code that uses GenericIPAddressField could fail unexpectedly. And now I'll shut up, because I'm not entitled to an opinion here yet :D Thomas

Re: Psycopg2 version support

2.5 is relatively easy to work around in contrib.postgres and a consistent minimum everywhere is more straightforward. There is just a conditional import on the fields.Range and forms.Range modules to deal with. I'd also add in a module level check that the psycopg2 version is OK, so that the

Re: Psycopg2 version support

Hi Wim, Thanks for the feedback. My thinking is that requiring 2.5 will needlessly cut off anyone who really wants to use an older version (like Debian stable), but patching contrib.postgres to work with < 2.5 will add complexity which we want to avoid. Here's the pull request that implements

Re: Psycopg2 version support

Hi, I am definitely in favor of just one version requirement in order not to complicate things. So then the minimum version would be either 2.5; or 2.4.5 and write special cases in contrib.postgres to deal with that. Regards, Wim On Monday, 16 February 2015 16:04:50 UTC+1, Tim Graham wrote:

Re: Drop the TEMPLATE_DEBUG setting

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': { # ...

Re: Drop the TEMPLATE_DEBUG setting

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

Re: Feature proposal: Allow shadowing of abstract fields

Hi Loïc, The implementation itself no longer depends on locks. I wish it was as simple as form fields, but the idea is the same. The first commit (https://github.com/knbk/django/commit/7ac5b58587ea2a153766d1601965734731609cdf) in fact leaves out the lock feature. It's still an extra option in

Re: status of 1.8 release blockers

There are still quite a few unresolved issues, so the beta release won't happen today. I'll send an update at the end of the day with the status of the remaining issues. On Friday, February 13, 2015 at 1:30:44 PM UTC-5, Markus Holtermann wrote: > > Hey folks, > > I looked into the issues

Re: Feature proposal: Allow shadowing of abstract fields

Hi Marten, As mentioned in my previous email I don't recommend an implementation based on locks. Please look at how Form and ModelForm support inheritance and shadowing without it. -- Loïc > On Feb 16, 2015, at 21:35, Marten Kenbeek wrote: > > Okay, as things were

Re: Psycopg2 version support

How about this plan: * Document 2.4.3 as the minimum if you don't want to use contrib.postgres * Recommend 2.5+ and document it as the minimum to use contrib.postgres * Require 2.5+ for Django's test suite to avoid having to add conditional imports/test skipping. On Monday, February 16, 2015 at

Re: Feature proposal: Allow shadowing of abstract fields

Okay, as things were getting more and more complicated I sat down for a while to get back to the essence of this patch. The result [1] is much, much cleaner and works perfectly. I'll start working on documentation as well. [1] https://github.com/knbk/django/tree/ticket_24305_alternative Op

Re: Drop the TEMPLATE_DEBUG setting

+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

Re: Psycopg2 version support

In CentOS 6, you can't run Django 1.8 anyway. It ships Python 2.6. So if you want to run Django 1.8 on CentOS 6, you need to compile Python yourself. In that case I don't think they'll complain about having to build psycopg2 separately as well. In the RHEL/CentOS universe, anyone who wants to

Re: Psycopg2 version support

My mistake, sorry. So, to get the conversation back on track, is `2.4.5` acceptable as the minimum version, even if users who - use CentOS 6 - install dependencies via the OS package manager - don't have sudo/root - can't request the sysadmin to install dev packages; and - keep django at the

Re: Drop the TEMPLATE_DEBUG setting

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

Re: Psycopg2 version support

Not exactly, cause installing psycopg2 via the OS package manager should __not__ require dev packages at all. On Monday, February 16, 2015 at 11:57:01 AM UTC+1, Thomas Stephenson wrote: > > > Installing psycopg2 does require development tools, while Django does not > > Installing psycopg2 2.0.0

Re: Drop the TEMPLATE_DEBUG setting

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 >

Re: Psycopg2 version support

Am Mon, 16 Feb 2015 01:15:53 -0800 (PST) schrieb Thomas Stephenson : > The postgres-*.*-dev libraries are a requirement for both 2.0.14 and > 2.5, so if it's possible to install 2.0.14 via the package manager > then it's possible to pip install 2.5. No, I believe this is not

Re: Drop the TEMPLATE_DEBUG setting

+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

Re: Psycopg2 version support

> Installing psycopg2 does require development tools, while Django does not. I'm not offering this as a compelling argument for anything, just an observation. The postgres-*.*-dev libraries are a requirement for both 2.0.14 and 2.5, so if it's possible to install 2.0.14 via the package

Re: Psycopg2 version support

> Installing psycopg2 does require development tools, while Django does not Installing psycopg2 2.0.0 requires exactly the same `postgres-*-dev` libraries that 2.5 does as far as I know. If it is possible to install psycopg2 via the OS package manager then 2.5 can be installed via pip. On

Re: Psycopg2 version support

For what it's worth, CentOS 6 (supported until November 30, 2020) ships with 2.0.14. CentOS 7 has 2.5.1. -- Gert Mobile: +32 498725202 Twitter: @gvangool Web: http://gertvangool.be On Mon, Feb 16, 2015 at 9:11 AM, Florian Apolloner wrote: >

Re: Psycopg2 version support

Core could stay at 2.4.5 and contrib.postgresql could require a newer version :) On Saturday, February 14, 2015 at 9:53:43 PM UTC+1, Marc Tamlyn wrote: > > Hi all, > > Related ticket - https://code.djangoproject.com/ticket/24335 > > Django 1.8 will necessarily be the first version with a true