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

[Julien Anguenot]

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:
> 

Right. It should be a message originating the bug report that mentioned
this information. My mistake...

I guess I did read this before :
http://mail.zope.org/pipermail/zope-dev/2004-February/021622.html

> (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.
> 

right. I'll try to reproduce this on 'pure' Python code.

> 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 feel it's related to Zope Python scripts but that's only suspicions
right now since all the errors we are having are in this context.

I'll dig more in it and see if I can get more information.

Thank you for the reply Tim.

	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/000c2bf0/signature.bin