You can take the WSGI script from my first post
<https://groups.google.com/group/modwsgi/msg/e6b9351c13c9a829> as test
case. I said before that the problem has nothing to do with the
virtualenv, you can just remove those few lines and get the same problem
just because as soon as an import happens, Python encodes the Unicode
entry from sys.path into the filesystem encoding - and since no codec
search function is registered, the LookupError is raised. Here is a
minimal WSGI test case (using Django import):
import sys
sys.path.insert(0, u'/tmp') # any Unicode will do
import django.core.handlers.wsgi
def application(environ, start_response):
response_headers = [("Content-Type", "text/plain"),
("Content-Length", "7")]
start_response("200 OK", response_headers)
return ["Worked."]
This will raise LookupError when trying to import the Django submodule.
Strangely, replacing it with "import time" (which is not in sys.modules
at that place!) works without problems, even though I put the Unicode
entry at the very beginning of sys.path...
And again my configuration: Debian squeeze, Apache 2.2, Django 1.2.5
installed with aptitude. Let's see if you can reproduce the same on Mac.
On 16.03.2011 17:32, Graham Dumpleton wrote:
> Am about to get on a couple of planes and will see if I can duplicate
> it on the Mac and get a small test case together that can log Python
> bug report for if needed. I wander if it is something more related to
> virtualenv only. Will be important to see if can duplicate it without
> virtualenv involved. Can't remember if you sent a standalone test
> case. Need to look through discussion properly.
>
> Graham
>
> On 16 March 2011 11:37, Joonas Lehtolahti <[email protected]> wrote:
>> [cut out the long post]
>>
>> Interesting, it seems like there really happens a difference between
>> initialization of sub-interpreters to the main one. But was there no errors
>> importing encodings in the sub-interpreters either, or did it not even try
>> to import the encodings package at all?
>>
>> For the record, I have all the encodings and stuff in all my Python
>> sub-interpreters and none of my pages are using global application group, so
>> it is not a generic problem that happens for everyone; just like with
>> EventScripts (the other project embedding Python I mentioned earlier) it
>> works fine for most people but fails to include the codecs for some people.
>>
>> It's too bad the error doesn't happen to me. If it did, I would surely dig
>> as deep as would be needed (even to edit Python's source code to add
>> additional debug messages) to find out what exactly causes it. I don't know
>> the internal structure of Python enough to be able to provide such edits for
>> remote debugging, though. But this is certainly an interesting problem and
>> not just mod_wsgi specific. If we can find out the cause and solution for
>> it, that would help not only your case but also plenty of people using other
>> embedded Python interpreters. (You might see that my motivation for actively
>> trying to participate in this particular problem is mostly because of the
>> similar problem in ES and there is a major pain that has been reported to
>> happen to more than just one user)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "modwsgi" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/modwsgi?hl=en.
>>
>>
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
