On 30 March 2010 13:44, Eric Abrahamsen <[email protected]> wrote: > On Tue, 2010-03-30 at 13:22 +1100, Graham Dumpleton wrote: >> 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])) > > Unfortunately it's just what you'd expect: <type 'module'> for those > entries with a valid __name__ and __file__, and <type 'NoneType'> for > those without. > > I tried this on my development setup, just for the heck of it, and got > the same results.
Looking at django.contrib.comments, all the so called modules listed in sys.modules which are supposed to be sub modules of that and which show as type None, don't exist within the Django source code. The question thus is, why on earth are there entries in sys.modules for them if they don't correspond to valid modules. That is truly bizzare and have never seen anything like that before. Can you post the code you are currently using to generate the response just so can ensure nothing obvious wrong being done? Also, in your tag library where you have: from comments.models import MyComment does: from comments.models import BaseCommentAbstractModel work instead. I am wandering whether the context in which the tag library is evaluated, whether it is picking up 'django.contrib.comments.models' instead for some reason and thus your problems are because of bad choice for your sub package in your application. If that second import works, then would possibly confirm that. What actually is in your 'comments.models'? Can you rename 'comments' to 'xcomments' in your site and change all the references and then see if it works without needing 'mysite' prefix. In other words 'comments' is very heavily overloaded in its usage and perhaps poor name to use for your own stuff. Graham Graham > Eric > >> >> 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.
