Re: About the django-core mailing list

On do, 2010-09-09 at 12:30 -0500, Jacob Kaplan-Moss wrote: > The goal is to only be private when we absolutely *must*, and if we're > not sufficiently transparent *please* say something. Thanks Jacob, for explaining this. This makes a good amount of sense, and Django is not unique here. I am

Re: Django 1.3 and Python 2.4

On Wed, Aug 11, 2010 at 2:20 AM, Russell Keith-Magee wrote: > Like it or not, RHEL is still a major player in the enterprise market > at the moment. I can't speak for the US, but in Australia at least -- > when all those companies got on the Linux bandwagon in the mid

Re: Querysets with "only()" and "defer()" slower than without?

On do, 2010-08-05 at 16:09 -0500, Jacob Kaplan-Moss wrote: > - What database engine are you using? > - Where's the database being stored (same server? other server? > in-memory?) > - How much data is in the database? > - How big is that "info" field on an average model? - Were OS/database level

Re: Allowing models to influence QuerySet.update

On wo, 2010-07-28 at 14:20 -0500, Jacob Kaplan-Moss wrote: > On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker > <den...@kaarsemaker.net> wrote: > > As implemented in my github branch it is called once (well, twice, pre > > and post) per update() statement, not once

Re: Allowing models to influence QuerySet.update

On wo, 2010-07-28 at 13:43 -0500, Jacob Kaplan-Moss wrote: > On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker > <den...@kaarsemaker.net> wrote: > > This would add boilerplate to each class and makes it nontrivial to do > > update() tracking for third party applicati

Re: Allowing models to influence QuerySet.update

-insignificant overhead. I'm of the opinion > that they should be avoided except where critically important, and I > don't see this to be one of those cases. > > On Wed, Jun 16, 2010 at 7:38 AM, Dennis Kaarsemaker > <den...@kaarsemaker.net> wrote: > > However, I'd like to

Re: Allowing models to influence QuerySet.update

Is nobody interested? I'm using this in production for auditing purposes and works just fine. If only it were built in, then I wouldn't have to monkeypatch :) I've rebased it to trunk again and it still works. On wo, 2010-06-16 at 14:38 +0200, Dennis Kaarsemaker wrote: > I k

Allowing models to influence QuerySet.update

I know that queryset.update does not call .save() for each instance and I know why. I even agree with it :) However, I'd like to have a bit more control over what update() does, e.g. for auditing purposes. I know that I can simply write a few lines of code near every update() call to do what I

Re: django bugfix releases

On di, 2010-05-25 at 17:22 -0700, Mikhail Korobov wrote: > I think the releases of stable micro-releases should happen more often > for 1.2. You guys are doing great job and it is not good to hide it > from developers. This issue has been raised before and improvements were promised. I believe

Re: Trac workflow assistance (commiter feedback needed)

On zo, 2010-04-25 at 23:15 +0800, Russell Keith-Magee wrote: > However, the *huge* impediment that you have avoided mentioning is > that moving to Launchpad would require moving Django to using Bazaar > for version control. You don't *have* to use the bzr/code bits of launchpad to use the

Re: Process discussion: reboot

On ma, 2010-04-19 at 15:47 +, Peter Landry wrote: > > > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" wrote: > > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry wrote: > >> One suggestion that jumped out at me (which I admittedly know very little > >>

Re: High Level Discussion about the Future of Django

On ma, 2010-04-05 at 23:25 +0800, Russell Keith-Magee wrote: > I'll freely admit that despite the major improvements landing in 1.2, > the development cycle itself hasn't been flawless. Hopefully I've been > able to provide some explanation for why things ended up the way they > did. You have,

Re: High Level Discussion about the Future of Django

On ma, 2010-04-05 at 21:47 +0800, Russell Keith-Magee wrote: > The bit that I have been engaging with is the discussion of (and > apparent misconceptions around) Django's backwards compatibility > policy, and our policies regarding support for older Python versions. And I appreciate that you

Re: High Level Discussion about the Future of Django

On ma, 2010-04-05 at 14:37 +0800, Russell Keith-Magee wrote: > For some perspective - even though Python 3.1 is out, dropping support > for Python 2.3 in Django 1.2 is being greeted as controversial in some > circles because RedHat Enterprise Linux 5 is still officially > supported by RedHat, and

Re: Does Python 2.6.5 broke Django 1.1.1 Client Test?

On ma, 2010-03-22 at 08:53 -0400, Karen Tracey wrote: > On Mon, Mar 22, 2010 at 4:07 AM, Raffaele Salmaso > wrote: > Marcob wrote: > > Please, does anybody know which patch I need to apply to > 1.1.1 to fix > > this strange problem? >

Re: Regarding httponly cookies

On wo, 2010-03-17 at 11:10 -0700, Yuchen Zhou wrote: > So does this ticket mean django now supports httponly cookies? And is > it by default httponly? > Or the application administrator has to turn it on? The discussion on http://code.djangoproject.com/ticket/3304 indicates that neither python

Re: Allowing models to influence QuerySet.update

On ma, 2010-03-08 at 08:09 +0800, Russell Keith-Magee wrote: > On Mon, Mar 8, 2010 at 7:56 AM, Dennis Kaarsemaker > <den...@kaarsemaker.net> wrote: > > I have now added tests and documentation. Comments are still welcome, I > > have not received any feedback yet :

Re: Allowing models to influence QuerySet.update

I have now added tests and documentation. Comments are still welcome, I have not received any feedback yet :( On wo, 2010-03-03 at 19:00 +0100, Dennis Kaarsemaker wrote: > I know that queryset.update does not call .save() for each instance and > I know why. I even agree with it :) >

Allowing models to influence QuerySet.update

I know that queryset.update does not call .save() for each instance and I know why. I even agree with it :) However, I'd like to have a bit more control over what update() does, e.g. for auditing purposes. I know that I can simply write a few lines of code near every update() call to do what I

Please apply fix for my pet bug

Yes, this is a shameless request to get my pet bug fixed :) A while ago I filed http://code.djangoproject.com/ticket/11448 -- this is the only bug that makes me have to ship a custom django version with my app, which I think is a shame. The problem is that doing anything that calls

Re: Proposal for __neq field lookup

On di, 2009-10-20 at 16:09 +0200, Michael P. Jung wrote: > Besides exclude(x=None).exclude(y=None).exclude(z=None) feels less > intuitive to me than filter(x__neq=None, y__neq=None, y__neq=None). That's what Q objects are for: .filter(~Q(x=None),~Q(y=None),~Q(z=None)) or: