Zope 2.7.0 rc2 + python 2.3.3 problem
I should have copied zope-dev, sorry. -------- Original Message -------- To: zope-coders@zope.org I'm having a weird failure here using Zope 2.7.0 rc2 and python 2.3.3 (Debian). When I execute a python script with the code: foo = range(1.0) I get this: Error Type: TypeError Error Value: unsubscriptable object Traceback (innermost last): * Module ZPublisher.Publish, line 104, in publish * Module warnings, line 57, in warn * Module warnings, line 63, in warn_explicit Instead of the expected: DeprecationWarning: integer argument expected, got float I don't know if it's python's fault or Zope's... But I guess python assumes too much about something as it fails in its standard libraries. If i use the code for i in range(1.0): pass The traceback is a bit longer: Error Type: TypeError Error Value: unsubscriptable object Traceback (innermost last): * Module ZPublisher.Publish, line 100, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Shared.DC.Scripts.Bindings, line 306, in __call__ * Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec * Module Products.PythonScripts.PythonScript, line 318, in _exec * Module None, line 1, in testbug <PythonScript at /testbug> Line 1 * Module AccessControl.ZopeGuards, line 210, in next * Module warnings, line 57, in warn * Module warnings, line 63, in warn_explicit TypeError: unsubscriptable object Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
[Florent Guillaume]
I'm having a weird failure here using Zope 2.7.0 rc2 and python 2.3.3 (Debian). When I execute a python script with the code:
foo = range(1.0)
I get this: Error Type: TypeError Error Value: unsubscriptable object Traceback (innermost last): * Module ZPublisher.Publish, line 104, in publish * Module warnings, line 57, in warn * Module warnings, line 63, in warn_explicit Instead of the expected: DeprecationWarning: integer argument expected, got float
I don't know if it's python's fault or Zope's... But I guess python assumes too much about something as it fails in its standard libraries.
If i use the code for i in range(1.0): pass The traceback is a bit longer:
Error Type: TypeError Error Value: unsubscriptable object Traceback (innermost last): * Module ZPublisher.Publish, line 100, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Shared.DC.Scripts.Bindings, line 306, in __call__ * Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec * Module Products.PythonScripts.PythonScript, line 318, in _exec * Module None, line 1, in testbug <PythonScript at /testbug> Line 1 * Module AccessControl.ZopeGuards, line 210, in next * Module warnings, line 57, in warn * Module warnings, line 63, in warn_explicit
TypeError: unsubscriptable object
Looks messy. It's dying here (in Python's warnings.py): def warn_explicit(message, category, filename, lineno, module=None, registry=None): if module is None: module = filename if module[-3:].lower() == ".py": ************ HERE ********* filename and module are both None at this point. That can't happen when running "real Python". The globals set up for running the script appear not to contain a '__file__' key, and have a '__name__' key explicitly set to None. If it set either of these to something useful, or didn't have a '__name__' key explicitly set to None, warning.warn() would have been able to make up *something* for warn_explicit's filename and/or module arguments.
Tim Peters wrote:
The globals set up for running the script appear not to contain a '__file__' key, and have a '__name__' key explicitly set to None. If it set either of these to something useful, or didn't have a '__name__' key explicitly set to None, warning.warn() would have been able to make up *something* for warn_explicit's filename and/or module arguments.
Argh. Scripts need a __name__ defined, or various activities choke. It can't be the Id of the Script, since that can contain '.', which screws up imports in the Script. It can't be None, since that will cause this problem. Are there hidden gotchas lurking around giving all Scripts the __name__ "Script (Python)"? Other suggestions? Cheers, Evan @ 4-am
[Tim Peters]
The globals set up for running the script appear not to contain a '__file__' key, and have a '__name__' key explicitly set to None. If it set either of these to something useful, or didn't have a '__name__' key explicitly set to None, warning.warn() would have been able to make up *something* for warn_explicit's filename and/or module arguments.
[Evan Simpson]
Argh. Scripts need a __name__ defined, or various activities choke. It can't be the Id of the Script, since that can contain '.', which screws up imports in the Script.
Since that's mondo obscure, let's point to your explanation: http://mail.python.org/pipermail/python-dev/2004-January/041749.html That's especially worth reading because of Guido's profusely apologetic response <wink -- "Too bad.">.
It can't be None, since that will cause this problem.
Are there hidden gotchas lurking around giving all Scripts the __name__ "Script (Python)"? Other suggestions?
I don't really know about Python Script, I've been talking about what Python's warnings module does. Perhaps you could use the Id of the script as __name__ after Id.replace('.', '-') (i.e., get rid of the dots)? Or it *looks* like you could leave name None, but set '__file__' to something (non-None) explicitly.
Tim Peters wrote:
it *looks* like you could leave name None, but set '__file__' to something (non-None) explicitly.
Thanks! This seems to do the trick, and I have a unit test that fails before and passes after the change. While creating the test, though, I ran across some disturbing behavior. In interactive mode (and when running unit tests) something is getting confused: Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
range(1.0) __main__:1: DeprecationWarning: integer argument expected, got float [0]
So far, so good. However: Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
__name__=None range(1.0) [] 1+1 Traceback (most recent call last): File "/usr/lib/python2.3/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/usr/lib/python2.3/warnings.py", line 63, in warn_explicit if module[-3:].lower() == ".py": TypeError: unsubscriptable object
...and... Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import warnings warnings.simplefilter("error", category=DeprecationWarning) range(1.0) [] 1+1 Traceback (most recent call last): File "/usr/lib/python2.3/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/usr/lib/python2.3/warnings.py", line 92, in warn_explicit raise message DeprecationWarning: integer argument expected, got float
...and... Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import pdb __name__ = None pdb.run('range(1.0)') <string>(1)?() (Pdb) s --Call-- /usr/lib/python2.3/warnings.py(24)warn() -> def warn(message, category=None, stacklevel=1): (Pdb) r --Return-- /usr/lib/python2.3/bdb.py:302: RuntimeWarning: tp_compare didn't return -1 or -2 for exception i = max(0, len(stack) - 1) [traceback snipped]
Looks like something isn't properly propagating exceptions. Cheers, Evan @ 4-am
[Evan Simpson]
... While creating the test, though, I ran across some disturbing behavior. In interactive mode (and when running unit tests) something is getting confused:
... [examples snipped] ... I copied the rest into a Python bug report, since it didn't appear to have anything to do with Zope anymore: http://www.python.org/sf/890010
Evan Simpson wrote:
Argh. Scripts need a __name__ defined, or various activities choke. It can't be the Id of the Script, since that can contain '.', which screws up imports in the Script. It can't be None, since that will cause this problem.
Are there hidden gotchas lurking around giving all Scripts the __name__ "Script (Python)"? Other suggestions?
Ages ago I suggested "__main__" because the newly instantiated code is sort-of a new top-level namespace for a sort-of python interpreter. But given all the issues that arrised with the other choices maybe there's lurking gotchas with "__main__" too. Anyway, thats my thought. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
participants (4)
-
Evan Simpson -
Florent Guillaume -
Jamie Heilman -
Tim Peters