Re: #12012 Logging: Final call for comments

2010-10-02 Thread Russell Keith-Magee
On Sat, Oct 2, 2010 at 8:59 AM, Kevin Howerton wrote: > Definitely agree.  Caught the missing nullhandler behavior when > logging is off too... though didn't make the connection that this was > likely intended to handle that case. > > It might make more sense to put this logic in conf/__init__.py

Re: #12012 Logging: Final call for comments

2010-10-02 Thread Vinay Sajip
On Oct 2, 1:59 am, Kevin Howerton wrote: > Also didn't realize that adding a nullhandler to just the root logger > would remove those warnings (pretty cool)... ended up writing a bit > that adds a nullhandler to any logger without handlers for my > implementation in lumberjack... woops. > Yes,

Re: #12012 Logging: Final call for comments

2010-10-01 Thread Kevin Howerton
Definitely agree. Caught the missing nullhandler behavior when logging is off too... though didn't make the connection that this was likely intended to handle that case. It might make more sense to put this logic in conf/__init__.py following the calls to configure the logger. Though that doesn'

Re: #12012 Logging: Final call for comments

2010-10-01 Thread Vinay Sajip
On Oct 1, 7:06 am, Russell Keith-Magee wrote: > > These are fairly minor modifications, so I'm still intending to commit > early next week, barring major objections. > As per my answer to Kevin - I think a NullHandler addition to the 'django' logger needs to happen internally (not under a site

Re: #12012 Logging: Final call for comments

2010-10-01 Thread Vinay Sajip
On Oct 1, 10:28 pm, Kevin Howerton wrote: > # Ensure the creation of the Django logger > logger = logging.getLogger('django') > I think the comment is misleading. I agree, there'd be no need to create the logger there as it doesn't seem to be used there. Two points: 1. Library code should add

Re: #12012 Logging: Final call for comments

2010-10-01 Thread Kevin Howerton
Hey... Discussed with Russell on IRC ... line 21 of log.py... # Ensure the creation of the Django logger logger = logging.getLogger('django') I guess it's trying to check if the logger exists? The getLogger method will actually never fail (as far as I'm aware), as nothing actually happens until

Re: #12012 Logging: Final call for comments

2010-10-01 Thread Vinay Sajip
On Oct 1, 3:45 am, Kevin Howerton wrote: > Regarding the 'version' setting.. .is that in the python 2.7 > implementation?  I ended up removing it from the included > logging-config in lumberjack as it wasn't really doing much. Yes, it's required so that we can introduce schema changes in future P

Re: #12012 Logging: Final call for comments

2010-09-30 Thread Russell Keith-Magee
Hi all, Following feedback from Jacob and others in IRC, I've just uploaded an RC2 patch. This patch: * Dramatically simplifies the logging configuration, removing everything that isn't absolutely required. * Adds a note in the project template settings.py telling the user what the default co

Re: #12012 Logging: Final call for comments

2010-09-30 Thread Kevin Howerton
re: verbose logging configuration. This bothered me as well initially, though after starting to use logging extensively I realized that there isn't really a more concise way to provide all of the features that the logging config brings to the table. We can however, create a very concise default s

Re: #12012 Logging: Final call for comments

2010-09-30 Thread Russell Keith-Magee
On Fri, Oct 1, 2010 at 1:53 AM, Andy McCurdy wrote: > Russ, > This will be a welcomed addition to debugging Django apps. I have a question > about startup.py. I notice that startup runs after settings are loaded, but > before models. Does this mean that code within startup.py cannot safely > acces

Re: #12012 Logging: Final call for comments

2010-09-30 Thread Andy McCurdy
Russ, This will be a welcomed addition to debugging Django apps. I have a question about startup.py. I notice that startup runs after settings are loaded, but before models. Does this mean that code within startup.py cannot safely access the ORM? If the ORM is fully accessible in startup.py, it's

Re: #12012 Logging: Final call for comments

2010-09-30 Thread Russell Keith-Magee
On Thu, Sep 30, 2010 at 10:03 PM, Jacob Kaplan-Moss wrote: > On Thu, Sep 30, 2010 at 8:56 AM, Russell Keith-Magee > wrote: >> If you have any objections, now is the time to raise them. > > This isn't an objection, per se -- don't let it stop you committing -- > but I'm somewhat concerned with the

Re: #12012 Logging: Final call for comments

2010-09-30 Thread Jacob Kaplan-Moss
On Thu, Sep 30, 2010 at 8:56 AM, Russell Keith-Magee wrote: > If you have any objections, now is the time to raise them. This isn't an objection, per se -- don't let it stop you committing -- but I'm somewhat concerned with the verbosity of the LOGGING setting. We're adding 40 lines of configurat

#12012 Logging: Final call for comments

2010-09-30 Thread Russell Keith-Magee
Hi all, A final call for comment before I commit #12012 to trunk. Barring objection, my intention is to commit this early next week. I've integrated the suggestions that have arisen since the first draft: * This patch has docs :-) There aren't any tests though, and I think it's going to have to