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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )