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

[Julien Anguenot]

Tres Seaver wrote:
> Tim Peters wrote:
>>> [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.
> 
> I wonder if Julian's problem stems from using the 'threadframe'
> extension, which is a prerequisite for the DeadlockDebugger;  I think I
> recall seeing an odd symptom like that in a sandbox where I had
> DeadlockDebugger running.
> 

Nope not in this case.

	J.


-- 
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20060211/dfd29761/signature.bin