[Zope-dev] Python warnings behavior and stacklevel=2

[Tim Peters]

[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=5470

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.