On Tue, 2010-03-30 at 22:06 +1100, Graham Dumpleton wrote: > 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?
I get this error on any page that tries to load the "entry_tags" tag library. That includes the index page, and anywhere else where comment totals or comments themselves are loaded. There's nothing special about the entry_tags library, I've pasted (what I hope are) the relevant bits here: http://pastebin.com/L0YUBLh4 Could this be happening because of the depth of the templatetags directory in my app structure? Every other place where the "from comments.models" statement works is directly under my app directory, only this one is buried one more directory deep... > > Also, in your tag library where you have: > > from comments.models import MyComment > > does: > > from comments.models import BaseCommentAbstractModel > > work instead. This is very weird. The above code never worked (ie, it always had to be "from mysite.comments.models import MyComment"), but changing this to: "from mysite.comments.models import BaseCommentAbstractModel" and then changing the code that follows to match it works -- it pulls the appropriate comment data from the appropriate table. Still can't do: "from comments.models import BaseCommentAbstractModel", though, it returns the same error. > > 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'? The class is called MyComment and it inherits from BaseCommentAbstractModel. I wanted to just call it Comment, since that's what it was, but I also discovered that the names are overloaded and that caused problems, I think with the database tables, I can't remember. I wanted something pretty much just like the built in comments but with some extra fields -- I can't quite remember why now but it seemed like the only way to do that was to recreate the builtin comments, with my own changes. Then there are a couple of other models in there, allowing people to register for comment notifications, and a pile of signals. > > Can you rename 'comments' to 'xcomments' in your site and change all > the references and then see if it works without needing 'mysite' > prefix. I'm hoping something in the above solves the problem -- since this issue only appears on the production site I'd rather not muck with class and table names unless it's a last resort! Thanks as always, Eric > > 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.
