Possible bug introduced in Django 1.7 admin/docs?
I was just playing around after upgrading from 1.6.6, I made small changes to my source to make it compatible. It was using the old WSGIHandler() style for wsgi.py, so I switched to get_wsgi_application(). I upgraded django-debug-toolbar, because it was incompatible. Everything on my site works. The admin works. Some of the admin/doc stuff works. However, when visiting admin/doc/filters this happened: Internal Server Error: /admin/doc/filters/ Traceback (most recent call last): File "/home/cjwelborn/lib/python3.3/django/core/handlers/base.py", line 111, in get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/home/cjwelborn/lib/python3.3/django/views/generic/base.py", line 69, in view return self.dispatch(request, *args, **kwargs) File "/home/cjwelborn/lib/python3.3/django/utils/decorators.py", line 29, in _wrapper return bound_func(*args, **kwargs) File "/home/cjwelborn/lib/python3.3/django/contrib/auth/decorators.py", line 22, in _wrapped_view return view_func(request, *args, **kwargs) File "/home/cjwelborn/lib/python3.3/django/utils/decorators.py", line 25, in bound_func return func.__get__(self, type(self))(*args2, **kwargs2) File "/home/cjwelborn/lib/python3.3/django/contrib/admindocs/views.py", line 43, in dispatch return super(BaseAdminDocsView, self).dispatch(*args, **kwargs) File "/home/cjwelborn/lib/python3.3/django/views/generic/base.py", line 87, in dispatch return handler(request, *args, **kwargs) File "/home/cjwelborn/lib/python3.3/django/views/generic/base.py", line 154, in get context = self.get_context_data(**kwargs) File "/home/cjwelborn/lib/python3.3/django/contrib/admindocs/views.py", line 100, in get_context_data load_all_installed_template_libraries() File "/home/cjwelborn/lib/python3.3/django/contrib/admindocs/views.py", line 314, in load_all_installed_template_libraries for p in os.listdir(os.path.dirname(upath(mod.__file__))) AttributeError: 'module' object has no attribute '__file__' It doesn't seem to touch any of my stuff, or any of the changes I mentioned previously. Only Django's stuff. Any ideas? -- \¯\ /¯/\ \ \/¯¯\/ / / Christopher Welborn (cj) \__/\__/ / cjwelborn at live·com \__/\__/ http://welbornprod.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/lvg84v%24qqt%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Possible bug introduced in Django 1.7 admin/docs?
On 09/18/2014 10:32 PM, I wrote: > Internal Server Error: /admin/doc/filters/ > "/home/cjwelborn/lib/python3.3/django/contrib/admindocs/views.py", line > 314, in load_all_installed_template_libraries > for p in os.listdir(os.path.dirname(upath(mod.__file__))) > AttributeError: 'module' object has no attribute '__file__' It does it for admin/doc/tags also. Not /models, /views, or /bookmarklets. -- \¯\ /¯/\ \ \/¯¯\/ / / Christopher Welborn (cj) \__/\__/ / cjwelborn at live·com \__/\__/ http://welbornprod.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/lvg92k%242vq%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Possible bug introduced in Django 1.7 admin/docs?
On 09/18/2014 10:50 PM, James Bennett wrote: > Are you using any third-party libraries which were installed as eggs? > It looks like I have several... Third-party extensions: django-extensions 1.3.3 django-solo 1.0.5 Non-extensions, but dependencies of extensions: sqlparse0.1.11 (django-debug-toolbar dependency) user_agents 0.2.0 (local extension dependency) ua_parser 0.3.5 (local extension dependency) Non-extensions, but imported: pyscopg2 2.5.2 pytidylib 0.2.3 twython 3.1.2 I am basing this on the fact that these all have [module-name].egg-info in my /dist-packages/ dir. I have a couple others that have no .egg-info. -- \¯\ /¯/\ \ \/¯¯\/ / / Christopher Welborn (cj) \__/\__/ / cjwelborn at live·com \__/\__/ http://welbornprod.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/lvga8q%24g1c%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Possible bug introduced in Django 1.7 admin/docs?
On 09/18/2014 10:50 PM, James Bennett wrote: > Are you using any third-party libraries which were installed as eggs? > Sorry, but was that supposed to be a hint to say "Don't use eggs"? I can see why it may fail looking for '__file__', but I don't understand why that is acceptable. Surely there should be some graceful error handling in the case that '__file__' is not available, instead of a hard 500 internal server error. Like if a third-party extension errors while looking for tags and filters, the extension would be skipped instead of halting. This is what made me think it was a bug. I don't want to file one if it's not though, so could someone enlighten me please? I am being sincere. Maybe I could even offer a patch for it. -- \¯\ /¯/\ \ \/¯¯\/ / / Christopher Welborn (cj) \__/\__/ / cjwelborn at live·com \__/\__/ http://welbornprod.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/lvhrv9%247v8%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Possible bug introduced in Django 1.7 admin/docs?
On 09/19/2014 08:26 PM, Russell Keith-Magee wrote: > So - James' comment should be interpreted as "Are you using eggs? Well, > there's your first problem". If you're actually using eggs, I'd strongly > encourage you to consider why, because there's almost certainly a better > way to distribute your code, and that way won't involve the random bugs > that eggs introduce. > > Also - to clarify; existence of an .egg-info file doesn't *necessarily* > mean you're using an egg - for historical reasons, the .egg-info file is > used for other packaging purposes. > > Yours, > Russ Magee %-) > Thank you for that response. You spelled it out perfectly. I'll look into my libraries and installation methods to see if there is something I can do on my end to help with my error. -- \¯\ /¯/\ \ \/¯¯\/ / / Christopher Welborn (cj) \__/\__/ / cjwelborn at live·com \__/\__/ http://welbornprod.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/lviq4j%24tau%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Get a memory profile for a django site?
I have a small personal site that runs on django, it's not a money-maker, and doesn't get a lot of traffic. I'm not so much a web-developer as I am an all-around programming enthusiast. I would like to find out how much memory a certain page or template/view is using. I know how much the apache process is using, and I know there are ways to profile python applications, I just don't know exactly where to go to get a nice picture and breakdown of what my django apps/pages are using. I've tried django-profiling-dashboard, but there were a couple issues I had to deal with and now I don't think I'm getting an accurate picture. What I mean is, I'm running Django 1.6 and Python 3.3, and profiling-dashboard had a small error with that setup. It was using the old django.conf.urls.default. I fixed that easily by patching it myself, only to find out that one of its dependencies (django-query-exchange) had the same error, plus more errors related to Django >= 1.5 and Python > 2.7. I hacked around those too, and got the dashboard running, but its kinda buggy (I haven't put a lot of time into it, as I wanted to ask some pros first). It gives me a profile that says '15Mb total', which I don't think is true. I think it's giving me a profile for only part of my site, but I wouldn't know which part. On my dev machine I have 2 apache processes that report ~8000 with the `ps` command fresh, and ~45000 each when I connect locally and the landing page is served. (thats with DEBUG==True, and debug-toolbar and all) Does anyone know how to get a memory-profile/breakdown on a Django 1.6/Python 3.3 site? Any help would be much appreciated. All of this doubles as a learning experience, and none of it is critical, so any and all ideas are welcome. Maybe even just a link to some reading material? -- - Christopher Welborn http://welbornprod.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/l88uvt%2451j%241%40ger.gmane.org. For more options, visit https://groups.google.com/groups/opt_out.
Get memory-use serverside when rendering a view?
My previous post was lengthy. I just need to find out how much memory is being used server-side when a view is rendered. I know it's possible to do this for regular python scripts, but I'm not sure how to measure my Django site. Django 1.6, Python 3.3, apache2, postgresql. Any help would be much appreciated, I won't mention it again if I don't receive an answer. -- - Christopher Welborn http://welbornprod.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/l8di7q%24ig8%241%40ger.gmane.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: Get memory-use serverside when rendering a view?
On 12/12/2013 06:19 PM, Jonathan Baker wrote: Django is just Python, after all, so you can use the same approach that you would in "regular python scripts". "when a view is rendered" is a pretty vague description of what you're aiming to profile. If your start point is the request coming in to Django, and your stop point is the rendered response exiting Django, then I'd write a piece of custom middleware. If, on the other hand, you're aiming to profile a specific method of a view (like rendering a template), then you'll want to target the method itself. You could do this with a decorator if you're using FBVs, or a abstract base class if you're using CBVs. This approach is nice because you're abstracting away the profiling code which allows you to easily reuse it. Hope this helps a little, JDB -- Jonathan D. Baker Developer http://jonathandbaker.com I appreciate your response, instead of using a lot of third-party apps I have written everything on my site from scratch to get things exactly the way I want them. I was actually hoping for a third-party solution for this one, but if it takes me writing my own middleware then thats just what I'll do. It is the whole request and response I am trying to look at, but finer grain control would be good too. Thanks again, I'm going to study up on middleware. -- - Christopher Welborn http://welbornprod.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/l8dtmt%241lm%241%40ger.gmane.org. For more options, visit https://groups.google.com/groups/opt_out.
