On 30 March 2010 12:35, Eric Abrahamsen <[email protected]> wrote: > On Tue, 2010-03-30 at 08:57 +1100, Graham Dumpleton wrote: >> On 29 March 2010 22:23, Eric <[email protected]> wrote: >> > Hi, I am 锁柱子 from the "improved wsgi script" blog post, thanks very >> > much Graeme for taking the time to look at this issue. I tried your >> > suggestions from the simplest first, running: >> > >> > python manage.py shell >> > import comments >> > comments.__file__ >> > >> > produced the right results both with and without the "mysite" >> > prepended to the import path. >> > >> > Then I added os.chdir('path/to/mysite') at the top of the wsgi script, >> > before anything else, but that didn't fix the problem. >> > >> > So I logged the calls to globals(), locals(), sys.modules.keys() and >> > sys.modules['comments'].__file__ as you indicated, inside the >> > templatetags library that's exploding. There's a heck of a lot of >> > stuff in there so I won't paste everything unless necessary. Logging >> > this in the "broken" setup (without "mysite" prepended to the import >> > path), I noticed first of all that in both locals() and globals(), >> > __file__ pointed to the correct file, but __name__ pointed to >> > "django.templatetags.entry_tags". I don't know if django munges import >> > paths to make it look like all templatetag libraries are housed under >> > "django.templatetags", but this looked odd to me. >> > >> > Nothing else immediately stood out. In sys.modules.keys() there are >> > the following comments-related entries, in the order they came out in >> > the list: >> > >> > comments.forms >> > django.contrib.comments.views.utils >> > django.contrib.comments.views.django >> > mysite.comments.forms >> > django.contrib.comments.templatetags >> > comments.admin >> > django.contrib.comments >> > django.contrib.comments.views.textwrap >> > mysite.comments.comments >> > django.contrib.comments.forms >> > comments.common >> > django.contrib.comments.views.comments >> > django.contrib.comments.time >> > django.contrib.comments.datetime >> > comments.comments >> > django.contrib.comments.admin >> > django.contrib.comments.signals >> > comments.pickle >> > django.contrib.comments.views.moderation >> > comments.django >> > django.contrib.comments.feeds >> > comments.datetime >> > django.contrib.comments.models >> > mysite.comments >> > myapp.comments >> > mysite.comments.django >> > comments >> > django.contrib.comments.managers >> > django.contrib.comments.views >> > django.contrib.comments.views.urllib >> > comments.akismet >> > django.contrib.comments.django >> > comments.models >> > >> > The one "myapp" entry is the app that has the exploding templatetags >> > library. >> > >> > I really have no idea if this is what I should be seeing or not... >> >> So I know where each is coming from, can you dump out: >> >> for name in sys.modules.keys(): >> if 'comments' in name: >> print name, sys.modules[name].__name__, sys.modules[name].__file__ >> >> Also dump out: >> >> print sys.path > > Here goes: http://python.pastebin.com/i7UA2V33 > > Perhaps significantly, many of the module values were actually None. I > had to check sys.modules[name] hasattr __name__/__file__ to avoid > throwing AttributeErrors for a 'NoneType' object. That's what the "No > name" and "No file" entries mean...
That doesn't make a great deal of sense. My recollection is that __name__ and __file__ should be set prior to global code in a module being executed and thus even if you have import cycles such that incompletely loaded modules are being imported, they at least should be set. The only other thing I can think of that would cause this is if they have implemented a lazy loading mechanism which replaces the module in sys.modules with a class instance that wraps the original module. These lazy loaders are a nuisance and can cause problems in multithreaded applications. I have in the past been quite suspicious of one lazy loader that does this in the Python standard library itself. Can you enhance that script to dump out: str(type(sys.modules[name])) In other words, find out what the type of object is that is in sys.modules. Graham -- 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.
