[Julien Anguenot]
I'm having some problems with the warnings module behavior. (Python-2.4.2 and Zope-2.9 trunk)
[... traceback ... ]
- Line 71 Module zLOG, line 140, in LOG Module warnings, line 61, in warn Module warnings, line 67, in warn_explicit TypeError: unsubscriptable object
It seems to be referenced on the Python tracker since Python-2.3.3. Has been fixed and closed but has been updated in January this year.
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id...
I expect that referencing that bug report is just misleading here: none of the bad behaviors listed in that bug report occur under Python 2.4.2 (I just tried all of 'em).
Specifying a stacklevel of a workaround, instead of 2 within the zLOG/__init__.py for instance1, as works fine. (and this seems to appear within the Python but report)
None of the provoking code in the bug report used stacklevel. There's a line of _output_ in the bug report, from a pdb session, where pdb showed the first line of the warnings.warn() function, showing that `stacklevel` is a formal argument of `warn()`, and that it defaults to 1: (Pdb) s --Call--
/usr/lib/python2.3/warnings.py(24)warn() -> def warn(message, category=None, stacklevel=1): # this is pdb output, not input
There's no other mention of `stacklevel` in the report.
I actually get the same error and behavior within CPS code using the warnings module with a stacklevel of 2.
Has someone a proper way to fix this from Zope and / or Python or can we simply change the StackLevel of the deprecation warnings to 1 waiting for a proper fix in Python ?
All the symptoms in the bug report are already fixed. In the absence of a new bug report, nothing else _will_ be fixed in Python related to this. The _cause_ of those bugs in the first place was an internal Python error: one of the internal functions didn't propagate exceptions properly back to the eval loop. It's possible that other cases like that exist, in Python itself or in a C extension module (it's actually a pretty common error in extension modules). Progress requires a small test case demonstrating the problem; the bug report contained several small test cases illustrating symtpoms, but all of those have been repaired, so if there's another bug it requires another test case to track it down.