[Zope-dev] Re: Zope 2.7.0 rc2 + python 2.3.3 problem

[Evan Simpson]

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

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 2.3.3 problem

[Evan Simpson]

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

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 2.3.3 problem

[Jamie Heilman]

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

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )