On Wed, 2010-10-06 at 12:24 +0800, Russell Keith-Magee wrote: > A fourth option would be to include Python's logging module, much as > we do with doctest, simpleJSON, and we're about to do with unittest2. > It's a heavyweight option, but it would do the job. We could remove > the inclusion once we drop Python 2.4 support (possibly in Django > 1.4).
Would this actually work? If any other library in someone's application uses 'import logging', they will get the system logging module, and unlike with those other libraries, this matters because logging has its own global objects and configuration etc. If we had our own in django.utils.logging, we would end up with two logging systems being used, which is going to get very ugly very quickly. The only way to avoid that is to put actually pull in the logging module as a top-level package, next to the django package, and hope that our version is found before the system one. That's seems a bit heavy, and especially tricky when it comes to which version we should bundle. For example, the logging module in Python 2.6 doesn't even parse under Python 2.4, but we certainly couldn't shadow someone's Python 2.6 logging module by putting the one from Python 2.5 before it on the Python path. That still leaves conditionally monkeypatching the logging module, but given the problem with configuration and globals etc, and different scenarios where applications might configure logging themselves, that really doesn't sound attractive either. Luke -- "Dysfunction: The only consistent feature of all of your dissatisfying relationships is you." (despair.com) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
