Re: Last chance to object to new features

On Tue, Nov 3, 2009 at 1:27 PM, Andi Albrecht wrote: > > On Mon, Nov 2, 2009 at 4:53 PM, Jacob Kaplan-Moss wrote: >> >> On Mon, Nov 2, 2009 at 10:02 AM, Russell Keith-Magee >> wrote: >>> A quick reminder - if you have

Re: Last chance to object to new features

On Mon, Nov 2, 2009 at 4:53 PM, Jacob Kaplan-Moss wrote: > > On Mon, Nov 2, 2009 at 10:02 AM, Russell Keith-Magee > wrote: >> A quick reminder - if you have any objections or feedback on #10109, >> the M2M refactor [1], I intend to land this patch in

Re: Enhanced debug output colors: django code is green, user code is red.

I'm not a big fan of the red/green either. They imply that Django code is "bad" and user code is "good". What about something more subtle, like different shades of gray for the background and/or text, to draw your attention to the user code while making it easier to gloss over the Django code

Re: Enhanced debug output colors: django code is green, user code is red.

I'm not sure about the exact colors, but the visual distinction is a big plus in my book. One possible place to document it would be in the information regarding the TEMPLATE_DEBUG setting here: http://docs.djangoproject.com/en/dev/ref/settings/#template-debug - Gabriel On Nov 2, 2:03 pm,

Re: Reversing URL for a view with namespaces

Speaking of the ways in which a namespace can be specified or provided, #11642 might be relevant here. http://code.djangoproject.com/ticket/11642 It feels a little cumbersome to me to require users to either manually specify a namespace or import a different object (than just the usual urls

Re: Enhanced debug output colors: django code is green, user code is red.

2009/11/2 Yuri Baburov > > Hi All, > > Since you are discussing and applying different features, > > I think it's time to ask what do you think of the subj. > > It's at http://code.djangoproject.com/ticket/11834 > > It adds some helpful color beauty to django 500 output. > >

Enhanced debug output colors: django code is green, user code is red.

Hi All, Since you are discussing and applying different features, I think it's time to ask what do you think of the subj. It's at http://code.djangoproject.com/ticket/11834 It adds some helpful color beauty to django 500 output. Sample pictures are here:

Re: https for code.djangoproject.com/svn

On Mon, Nov 2, 2009 at 12:23 PM, Alexander Konovalenko wrote: > Personally I can live without full SSL support because there are > work-arounds, but svn checkout over SSL is essential for me. It's on my todo list. Jacob --~--~-~--~~~---~--~~

https for code.djangoproject.com/svn

I would like to check out the Django source from the Subversion repository but I use an untrusted network connection. Currently there's no easy way to verify the integrity of the code I got after doing svn co http://code.djangoproject.com/svn/django/trunk/ It would be nice if

Re: Transactions

Isn't it TRANSACTION_MANAGE = True? Ben On 2 Nov, 17:19, Jacob Kaplan-Moss wrote: > On Mon, Nov 2, 2009 at 11:27 AM, Ben Ford wrote: > > I'm really curious though -- can anyone remember far back enough to > > know where this came from? I haven't been

Re: Transactions

On Mon, Nov 2, 2009 at 11:27 AM, Ben Ford wrote: > I'm really curious though -- can anyone remember far back enough to > know where this came from? I haven't been able to find a single > mention of DISABLE_TRANSACTION_MANAGEMENT  anywhere in django's > history! I'm pretty

Transactions

Hi All, I'm looking into the transaction module due to an app that I'm working on doing something very odd (and mostly indefensible) with long running transactions. It would seem that the docs are totally off base WRT to transactions - specifically the DISABLE_TRANSACTION_MANAGEMENT setting.

Re: Last chance to object to new features

On Mon, Nov 2, 2009 at 10:02 AM, Russell Keith-Magee wrote: > A quick reminder - if you have any objections or feedback on #10109, > the M2M refactor [1], I intend to land this patch in approximately 48 > hours. I've left a few comments in that thread, but they don't

Re: Call for feedback: First GSoC patch ready to land

Hi Russ -- I'm +1 on merging the patch immediately. I have some feedback on the couple of issues you raised below, but I see no reason they can't be addressed after merging. On Fri, Oct 30, 2009 at 3:33 AM, Russell Keith-Magee wrote: > The automatically generated m2m

Re: Advocacy for Email-01 (email backends)

On Oct 30, 2009, at 6:10 AM, Russell Keith-Magee wrote: > I'm still keen to see a resolution to this problem. Can anyone - > especially those that voted -0 or -1 - offer any feedback? I've reviewed the RC patch on #10355. Overall, I am okay with it. I hadn't kept up with with many of the

Last chance to object to new features

Hi all, A quick reminder - if you have any objections or feedback on #10109, the M2M refactor [1], I intend to land this patch in approximately 48 hours. Also, following some mailing list and IRC discussion [2], I'll be trying to land #10355 at the same time. This is the addition of the email

Re: QuerySet.exists() and __nonzero__

On Mon, Nov 2, 2009 at 4:35 AM, Jiri Barton wrote: > I was wondering if a consensus has been reached and __nonzero__ > could use the new QuerySet.exists()? This was discussed, and Luke explains why __nonzero__ can't do this optimization here:

QuerySet.exists() and __nonzero__

Hello everyone, I listened to the Django Dose this morning and to my great delight, found QuerySet.exists() has landed in the trunk. I did not however hear anything about yes or no on using __nonzero__ on the interface side. Having read this thread