Python warnings behavior and stacklevel=2
Hi there, 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... 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) 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 ? Cheers, 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
[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...
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.
-----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...
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@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-----
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...
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
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...
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
Julien Anguenot 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
I've had this too, and I believe it appears if you have a frame referencing a python script (or maybe an external method) in the stack. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote:
Julien Anguenot 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
I've had this too, and I believe it appears if you have a frame referencing a python script (or maybe an external method) in the stack.
You'll get the error if you run the CPSDefaul tests against a Zope-2.9 branch, for instance. 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
This turned out to be a bug in FSPythonScripts (no __file__ in script globals). Fixed on all branches of CMF >= 1.5. Cheers, Stefan On 13. Feb 2006, at 16:48, Julien Anguenot wrote:
Florent Guillaume wrote:
Julien Anguenot 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
I've had this too, and I believe it appears if you have a frame referencing a python script (or maybe an external method) in the stack.
You'll get the error if you run the CPSDefaul tests against a Zope-2.9 branch, for instance.
-- Anything that happens, happens. --Douglas Adams
Stefan H. Holek wrote:
This turned out to be a bug in FSPythonScripts (no __file__ in script globals). Fixed on all branches of CMF >= 1.5.
Great ! Thanks. J.
On 13. Feb 2006, at 16:48, Julien Anguenot wrote:
Florent Guillaume wrote:
Julien Anguenot 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
I've had this too, and I believe it appears if you have a frame referencing a python script (or maybe an external method) in the stack.
You'll get the error if you run the CPSDefaul tests against a Zope-2.9 branch, for instance.
-- Anything that happens, happens. --Douglas Adams
-- 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
participants (5)
-
Florent Guillaume -
Julien Anguenot -
Stefan H. Holek -
Tim Peters -
Tres Seaver