Re: patch for # 7270, select_related cannot follow reverse one-to-one relationship

On Fri, Sep 18, 2009 at 2:49 AM, Ben Davis wrote: > I noticed this ticket is currently assigned to Malcolm; in the comments he > says it's on his list of patches to work on.   It looks like the last thing > he did was set the milestone to 1.2 back in March,  but haven't

Re: Proposal for 1.2: built-in logging with django.core.log

On Sep 17, 6:25 pm, Simon Willison wrote: > I think we should add logging to Django in version 1.2, implemented as > a light-weight wrapper around the Python logging module > (django.core.log maybe?) plus code to write errors to the Apache error > log under the

Re: CSRF proposal and patch ready for review

Hi Simon, OK, here is my response. I hope this doesn't turn into a personal my-code-vs- your-code match (especially as most of "my code" is really other people's code and ideas :-) but I want to make sure we do this right, as it potentially has big implications, so the following will be

Re: Proposal for 1.2: built-in logging with django.core.log

On Sep 17, 4:04 pm, Russell Keith-Magee wrote:  > I've seen several attempts to wrap Java loggers in a "nicer" > interface, and every one of them ended up hobbling some of the power > features of the logger. There is also the issue of our wrapper playing > nicely with the

Re: Proposal for 1.2: built-in logging with django.core.log

On Sep 17, 10:25 am, Simon Willison wrote: > That's 0.0006 of a second overhead for a page logging 100 SQL > statements. The performance overhead will go up if you attach a > handler, but that's fine - the whole point of a framework like > 'logging' is that you can log

Re: Change list default sort modification proposal

I don't have any say in what gets accepted or not but I do believe that your solution is a decent one. I'm continuing with mine because it addresses a current need simply and can be (fairly) easily tested. If you can create the regression tests for yours then I believe you might get more traction.

Re: Question on ticket triage process

On Thu, Sep 17, 2009 at 1:38 PM, Ben Davis wrote: > So by documentation,  do you mean updating the official django docs,  or > better documentation in the code itself? Yes :) As a general rule: * Self-documenting code is fine sans comments, but anything non-obvious needs

Re: patch for # 7270, select_related cannot follow reverse one-to-one relationship

I noticed this ticket is currently assigned to Malcolm; in the comments he says it's on his list of patches to work on. It looks like the last thing he did was set the milestone to 1.2 back in March, but haven't seen any comments on the ticket from him since then. Is it considered fair game

Re: Change list default sort modification proposal

I'm not sure if anyone's seen this, but I've written a patch for multi-sort columns in the changelist ui here: http://code.djangoproject.com/ticket/11868 Not sure if this is what you guys had in mind, but I'd be interested in your feedback. On Thu, Sep 17, 2009 at 12:57 PM, Joshua Russo

Re: Proposal for 1.2: built-in logging with django.core.log

+1 on the logging proposal. The stock python logging module is definitely a bit of a finicky and confusing creature, especially for people coming to Python for the first time with Django. -0 On the signals based approach. I would be wary of the potential performance overhead of replacing

Re: Question on ticket triage process

So by documentation, do you mean updating the official django docs, or better documentation in the code itself? On Sat, Sep 12, 2009 at 2:15 PM, Eric Holscher wrote: > At first glance, tests and documentation. Everything needs both of these > things before they go into

Re: Change list default sort modification proposal

Sorry for dragging this back out of the depths but I was reviewing my code for regression testing and I noticed I had missed this comment way back when. Where is this named sort option documented? It seems to me that the implementation that I have here would still be useful even if you could

Re: Proposal for 1.2: built-in logging with django.core.log

On Sep 17, 1:25 am, Simon Willison wrote: > 1. We'll be able to de-emphasise the current default "e-mail all > errors to someone" behaviour, which doesn't scale at all well. I'm a big fan of this proposal, for exactly this reason. +1 Thanks, Eric Florenzano

Re: #9886: HttpRequest refactoring

Jacob Kaplan-Moss wrote: > On Thu, Sep 17, 2009 at 10:09 AM, Ivan Sagalaev > wrote: >> Ticket [9886] is one of the things that I've been holding for 1.2 time >> frame to ask for some discussion since Jacob marked it DDN. > > At first glance, you need docs and tests

Re: #9886: HttpRequest refactoring

Ivan Sagalaev wrote: > This comment[1] in the ticket is a summary of what had changed. Thanks > for looking! Forgot to add... There's no docs & tests changes in the patch yet. I'll add them after the decision if this looks good at all. --~--~-~--~~~---~--~~ You

Re: #9886: HttpRequest refactoring

On Thu, Sep 17, 2009 at 10:09 AM, Ivan Sagalaev wrote: > Ticket [9886] is one of the things that I've been holding for 1.2 time > frame to ask for some discussion since Jacob marked it DDN. At first glance, you need docs and tests before you get a second glance :)

#9886: HttpRequest refactoring

Hello everyone! Ticket [9886] is one of the things that I've been holding for 1.2 time frame to ask for some discussion since Jacob marked it DDN. This has started as a feature allowing to .read() directly from a request object. However this has lead to a rather nice refactoring removing a

Re: proposal: decouple admin index page from INSTALLED_APPS

just for the records ... as russell commented on the ticket, this can all be done with subclassing AdminSite. so ... here´s how grouping and reordering app with the admin-interface can be achieved: http://code.google.com/p/django-grappelli/wiki/customizingindex and here´s the code (subclassing

Re: Patch Review - #9638

Sweet, thanks a bunch! Lakin On Sep 17, 8:31 am, Jacob Kaplan-Moss wrote: > On Thu, Sep 17, 2009 at 9:26 AM, lakin wrote: > > Does anyone have the time to review the patch, please? > > Looks good; I've marked it ready for commit. > > Jacob

Re: Proposal for 1.2: built-in logging with django.core.log

On Thu, Sep 17, 2009 at 10:04 AM, Russell Keith-Magee wrote: > As for likely roadblocks: I've been led to believe that Adrian has > objections to framework-level logging. I have no idea as to the nature > of his objection, but ticket #5415 indicates that he is (or has

Re: Patch Review - #9638

On Thu, Sep 17, 2009 at 9:26 AM, lakin wrote: > Does anyone have the time to review the patch, please? Looks good; I've marked it ready for commit. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the

Patch Review - #9638

I'd like to help facilitate the application of the patch on http://code.djangoproject.com/ticket/9638 to trunk and potentially in any releases that it would make sense to include it in. I've been told that I should politely ask for a patch review on the mailing list. Does anyone have the time

Re: Proposal for 1.2: built-in logging with django.core.log

On Thu, Sep 17, 2009 at 4:25 PM, Simon Willison wrote: > > I think we should add logging to Django in version 1.2, implemented as > a light-weight wrapper around the Python logging module > (django.core.log maybe?) plus code to write errors to the Apache error > log

Re: Proposal for 1.2: built-in logging with django.core.log

On Thu, Sep 17, 2009 at 6:53 PM, Ivan Sagalaev wrote: > > Hi Simon, > > Simon Willison wrote: >> 1. We'll be able to de-emphasise the current default "e-mail all >> errors to someone" behaviour, which doesn't scale at all well. > > In a recent thread[1] on a similar

Re: CSRF proposal and patch ready for review

All good points - the change in function signature naturally fell out of the CSRF work (since the form needs access to the request object in both cases) but you've convinced me that it's a step too far - I'll see if I can fix that. Cheers, Simon On Sep 17, 2:10 pm, Russell Keith-Magee

Re: CSRF proposal and patch ready for review

On Thu, Sep 17, 2009 at 3:11 PM, Simon Willison wrote: > > On Sep 15, 2:57 pm, Luke Plant wrote: >> OK, I'll wait and see. > > Here's the code: http://github.com/simonw/django-safeform > >>  * it requires using Django's form system.  I've got

Re: SoC merge plans?

On Thu, Sep 17, 2009 at 4:35 PM, Simon Willison wrote: > > On Sep 13, 12:52 pm, Russell Keith-Magee > wrote: >> Although the branch isn't ready for merge yet, the code that is >> present is all up to spec. I think the sprints have produced

Re: proposal: decouple admin index page from INSTALLED_APPS

I´ve opened a ticket with my patches (and a screenshot): http://code.djangoproject.com/ticket/11895 I´ve given up on changing the app-index page since this seems to break the overall coherence of the admin-interface. therefore, my patch doesn ´t change the breadcrumbs. it only gives you the

Re: Proposal for 1.2: built-in logging with django.core.log

Hi Simon, Simon Willison wrote: > 1. We'll be able to de-emphasise the current default "e-mail all > errors to someone" behaviour, which doesn't scale at all well. In a recent thread[1] on a similar topic Russel has also emphasized that we should improve documentation about doing logging. >

Re: Proposal for 1.2: built-in logging with django.core.log

Definitely a +1 from me. -- Horst On Thu, Sep 17, 2009 at 10:25 AM, Simon Willison wrote: > > I think we should add logging to Django in version 1.2, implemented as > a light-weight wrapper around the Python logging module > (django.core.log maybe?) plus code to write

Re: Proposal for 1.2: built-in logging with django.core.log

+1 for this, another random thought which doesn't do your long post justice. But what are everyone's thoughts about log aggregation, taking logs from X app servers and combining them into a single location, something like Facebook's Scribe. I assume this could be built in as a separate log

Re: Customizing URL resolver

On Sep 16, 4:14 pm, matehat wrote: > Oh, and trying to make the url resolving mechanism look in the > database is really a bad idea because it would trigger a bunch of > database queries every time a request is processed by your > application, which would really slow

Re: Customizing URL resolver

On Sep 16, 4:11 pm, matehat wrote: > Hi, > > If the url only depends on the object's id (which I suppose don't > change with time), The only problem is, it doesn't :-) We'd like to be able to handle redirects. E.g. category "wine" is renamed to "wines", but we still

Re: Replacing get_absolute_url, I am against it

On Sep 15, 12:04 pm, Ivan Sagalaev wrote: > James Bennett wrote: > > Except I can't help thinking this is an awfully arbitrary distinction > > to draw. In effect you're saying that nearly every question about an > > object should be answerable by interrogating it

Re: SoC merge plans?

On Sep 13, 12:52 pm, Russell Keith-Magee wrote: > Although the branch isn't ready for merge yet, the code that is > present is all up to spec. I think the sprints have produced workable > solutions for the outstanding problems; fixes implementing the > solutions we

Proposal for 1.2: built-in logging with django.core.log

I think we should add logging to Django in version 1.2, implemented as a light-weight wrapper around the Python logging module (django.core.log maybe?) plus code to write errors to the Apache error log under the mod_python handler and environ['wsgi.errors'] under WSGI (meaning mod_wsgi will write

Re: CSRF proposal and patch ready for review

On Sep 15, 2:57 pm, Luke Plant wrote: > OK, I'll wait and see. Here's the code: http://github.com/simonw/django-safeform >  * it requires using Django's form system.  I've got plenty of views that > don't (e.g. anything with a dynamic number of controls).  People not