Both yours and simon wilsons solutions look like great solutions. Though possibly over-arching for an initial implementation of logging, but if an implementation like that makes it into 1.3 in one fell swoop I would be as happy as a clam.
Making use of python's built-in logging facility should be a very high priority for any python project that considers itself worthy of being used in production environments. You guys are definitely taking the right direction .... having comprehensive logging coverage in my opinion is more important than having comprehensive test coverage. What I was suggesting in my post though, was that we alter the default CRITICAL error handling behavior ... as it stands (by default) all of my ERRORs are being suppressed in production. This is pretty confusing for new users (there were 3 others in IRC with the same complaint yesterday), and pretty un-pythonic IMO. Unless I missed something? At minimum the documentation should inform the user of this short-coming, and provide a link to a wiki with the available work-arounds. Leaving out logging of critical errors because we don't currently have the perfect all encompassing logging solution, is not the decision I would have made. Doing things in an iterative cycle might work better. Step 1: do what you need to have done. Step 2: do what you want to have done. Leaving out critical stuff because you don't know what you want, when you know what you need that is critical is no bueno. It's like not setting a broken arm because you can't decide on what color you want the fiber glass to be. -k ps. I don't want to get into a flamewar (although it is certainly one of my specialities... and prefacing this paragraph with this sentence probably won't help the cause), though after reading that thread I felt like this needed to be said. No one here (me included) is allowed to call a *built-in* Python library un-pythonic.... especially the logger. So it shares some similarities with Java? Some stuff in Java is awesome. Some stuff in Ruby is awesome. Some of the stuff in Rails is awesome. Some stuff in C# is awesome. Some stuff in Perl is awesome. I've luckily been able to avoid PHP for my entire career, but I'm sure there is something really nice about PHP too. The very reason python is such a great language is *because* it takes some (possibly even all of it) of the awesome stuff from a variety of technologies, not because it wildly diverges and does things uniquely. I see a lot of this pretentiousness in the programming community in general, and really it is pretty detrimental to who-ever ends up spouting it off. It's very reductionist. Ignoring prior art just because it was written in ruby, or targets rails, or runs on the JVM, or uses CamelCase for function names is stupid. On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > > On May 5, 4:47 am, Kevin Howerton <kevin.hower...@gmail.com> wrote: > > I think the plan was to look at integrating logging after the 1.2 > release was done. The original discussion was here: > > http://groups.google.com/group/django-developers/browse_frm/thread/8551ecdb7412ab22/ > > With Django's configuration style, it would be beneficial to use > dictionary-based configuration as introduced in PEP 391 and > implemented in Python trunk (2.7/3.2). For older Python versions, > Django could use my standalone implementation of PEP-391 functionality > available at > > http://bitbucket.org/vinay.sajip/dictconfig/ > > I have a Django branch which shows how logging can be easily > integrated during startup, and it's at > > https://code.launchpad.net/~vinay-sajip/django/logging > > It's a proof-of-concept, last merged with trunk in Jan 2010, but the > changes are simple so it shouldn't be a problem to bring up to date. > I'll look at doing this once 1.2 is out. > > Regards, > > > Vinay Sajip > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
