Traceback (most recent call last):
File "<string>", line 1, in ?
ImportError: No module named _mysql
According to Python documentation modules are shared between subinterpreters - first interpreter imports module , while second ones only creates shallow copy. Maybe it goes wrong ???
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Guido, one thing _mysql does, which is probably too common, is import a Python module (_mysql_exception) during the module init. I hope it is legal to do this...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks like you could be onto something here, Andy.
I compiled a bodged version of _mysql.c with the Import call and the follow emod-related code commented out, and the site-packages-not-being-in-sys.path problem went away. Of course MySQLdb doesn't work like this, but I can import it harmlessly. :-)
No idea why this should happen, but it shouldn't be too hard to do the exceptions a different way should it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-10-16
I also thought it is problem with _mysql.
I've tried other (standard) Python modules and everything works ok.
Thanks for answer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Check out sys.path. The first interpreter's sys.path includes site-packages at the end, the second does not. This is the root of the problem.
I have experienced this with PyApache. If _mysql is imported, then sys.path will be missing the final site-packages element the next time the interpreter is re-used.
Very strange.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I've got problem when creating new Python subinterpreters after I've imported _mysql.
In real program I'm creating new subinterpreter for separate thread, but this simple example also shows my problem.
int main()
{
char * cmd = "import _mysql\nprint \"ok\"";
PyEval_InitThreads();
Py_Initialize();
Py_NewInterpreter();
PyRun_SimpleString(cmd);
Py_NewInterpreter();
PyRun_SimpleString(cmd);
Py_Finalize();
return 0;
}
Second call of Py_NewInterpreter shows message:
'import site' failed; use -v for traceback
Second call of PyRun_SimpleString shows:
Traceback (most recent call last):
File "<string>", line 1, in ?
ImportError: No module named _mysql
According to Python documentation modules are shared between subinterpreters - first interpreter imports module , while second ones only creates shallow copy. Maybe it goes wrong ???
This may be a problem with the mysql extension module.
For a working example, look at Demo/pysvr/ in the source distribution.
Guido, one thing _mysql does, which is probably too common, is import a Python module (_mysql_exception) during the module init. I hope it is legal to do this...
Looks like you could be onto something here, Andy.
I compiled a bodged version of _mysql.c with the Import call and the follow emod-related code commented out, and the site-packages-not-being-in-sys.path problem went away. Of course MySQLdb doesn't work like this, but I can import it harmlessly. :-)
No idea why this should happen, but it shouldn't be too hard to do the exceptions a different way should it?
I also thought it is problem with _mysql.
I've tried other (standard) Python modules and everything works ok.
Thanks for answer
Check out sys.path. The first interpreter's sys.path includes site-packages at the end, the second does not. This is the root of the problem.
I have experienced this with PyApache. If _mysql is imported, then sys.path will be missing the final site-packages element the next time the interpreter is re-used.
Very strange.