This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: odd behavior when reloading "exceptions"
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gvanrossum, jhylton, michaelklatt
Priority: normal Keywords:

Created on 2001-04-21 21:57 by michaelklatt, last changed 2022-04-10 16:03 by admin. This issue is now closed.

Messages (4)
msg4465 - (view) Author: Michael Klatt (michaelklatt) Date: 2001-04-21 21:57
After reloading the "exceptions" module, "exceptions.OSError" is not the same object as "os.error".

Let me illustrate by example:


# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os, exceptions
>>> os.error == exceptions.OSError
1
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> os.error == exceptions.OSError
0
>>>


Here's an example of how this could wreak havoc in a python script:

# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> import exceptions
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
exception caught
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in ?
OSError: [Errno 2] No such file or directory: 'dummy'
>>> 


A quick test shows that this problem also occurred in python 1.5.2 and python 2.0.  I believe I 
understand why this is happening (when the exceptions module is reloaded, a new object for 
OSError is created), but I'm hoping someone has a creative solution.  

This will cause problems in any application which calls Py_NewInterpreter() (like mod_python).  
To verify this, add the following lines to Demo/embed/demo.c at line 36:

 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");
 
        Py_NewInterpreter(); 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");

The first comparison will result in 1, and the second will result in 0. 

Thanks!

Mike

msg4466 - (view) Author: Michael Klatt (michaelklatt) Date: 2001-04-22 06:44
Logged In: YES 
user_id=201661


I did find a workaround for mod_python (and any application that uses Py_NewInterpreter()...).  I modified it 
to add this line after *every* call to Py_NewInterpreter()

PyRun_SimpleString("__import__(\"os\").error = __import__(\"exceptions\").OSError\n");

This is ugly, but it's a works.

Mike
msg4467 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2001-05-09 16:00
Logged In: YES 
user_id=31392

It seems like a bug, except that it also seems obviously
correct <wink>.  Any opinion about whether we should fix
this?
msg4468 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2001-08-10 19:11
Logged In: YES 
user_id=6380

This is the same problem as bug #449151, but it was easier
to fix this appearance: I simply prevented exceptions from
being reloaded. 

Fixed in CVS.
History
Date User Action Args
2022-04-10 16:03:59adminsetgithub: 34390
2001-04-21 21:57:14michaelklattcreate