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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD7eYE+gerLs4ltQ4RApvkAKDS3yQr37LnaMWdeF+Lvqn3cmoTrQCdGoii
YoouyJGeK0iaU8Fcg78YN6c=
=4EPS
-----END PGP SIGNATURE-----