Hello, David MENTRE <[EMAIL PROTECTED]> writes:
> Last minute update: there is apparently an issue when trying to reach a > question's details: in works fine with a localhost URL but not with the > above one. I don't know why and moreover the issue seems transient. :-( I tried to investigate this issue. Here is the error I get: """ Mod_python error: "PythonHandler mod_python.publisher" Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/lib/python2.5/site-packages/mod_python/publisher.py", line 213, in handler published = publish_object(req, object) File "/usr/lib/python2.5/site-packages/mod_python/publisher.py", line 412, in publish_object return publish_object(req,util.apply_fs_data(object, req.form, req=req)) File "/usr/lib/python2.5/site-packages/mod_python/util.py", line 439, in apply_fs_data return object(**args) File "/var/www/lyu-proto/python/login.py", line 472, in consult_question tag_list = question_tags[qu_id]['tag_set'] NameError: global name 'question_tags' is not defined """ As far as I have understood, when looking at a question details the function "consult_question()" is called. This function uses the global variable "question_tags" which, at this time, is undefined. This variable is defined in function "login()". For some reason, this definition is lost when going from the list of question (calling "login()") to the question details (calling "consult_question()"). I suspect this is due to the fact we can have several Python interpreters, each one handling a request. For example, the first Python interpreter could handle the "login()" while a second one the call to "consult_question()". That would explain why the variable is undefined in the second function. I'm using Apache2 in MPM (Multi-Processing Module) prefork mode, which could creates multiple interpreters (one per forked apache2 process). But all this is a wild guess, I've not been able to find a way to verify if all of this is true or not. Anyway, a way to fix the bug would be to check that the variable "question_tags" does exist and, if this not the case, create it by calling an appropriate function. I haven't done it yet. Yours, d. -- GPG/PGP key: A3AD7A2A David MENTRE <[EMAIL PROTECTED]> 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A _______________________________________________ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev