This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Bluebird75
Recipients Alexandr, Bluebird75, ncoghlan, python-dev, r.david.murray, vinay.sajip
Date 2013-03-25.13:12:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1364217137.24.0.32793699776.issue12718@psf.upfronthosting.co.za>
In-reply-to
Content
This issue is closed, but the problems remain that the current version of winpdb is incompatible with django + python 2.7 .

I don't really understsand why the issue is closed without any change to python logging library itself.

To sum-up the issue:
1. django uses some standard interface of logging
2. winpdb replaces the builtin __import__ with a custom python function
3. logging stores the __import__ value in a class attribute
4. python calls class attributes differently whether they are a builtin function (direct function call) or python function (which becomes a bound method, receiving self as first argument).

The problem comes from point 4, but the root of the problem is that logging assumes that it is always storing a builtin function.

The documentation fix does not fix the problem. 

How could winpdb apply this fix ? Should it check that the argument passed to its import replacement are not by mistake a DictConfigurator instance (bound method of logging class) ? That sounds like an ugly workaround for a problem lying in python logging module.

The correct fix is that logging should not assume importer to be a builtin function and add some flexibility around this.
History
Date User Action Args
2013-03-25 13:12:17Bluebird75setrecipients: + Bluebird75, vinay.sajip, ncoghlan, r.david.murray, python-dev, Alexandr
2013-03-25 13:12:17Bluebird75setmessageid: <1364217137.24.0.32793699776.issue12718@psf.upfronthosting.co.za>
2013-03-25 13:12:17Bluebird75linkissue12718 messages
2013-03-25 13:12:16Bluebird75create