On Mon, May 17, 2010 at 10:00 AM, Charlie Nolan <funnyman3...@gmail.com> wrote: > It seems to me like the biggest problem with a settings module not > importing is that it's not safe to display a full error message about > that file. You can't tell if DEBUG is on, and there may well be > information in the settings that is a Bad Idea to leak on a production > server. > > Also, as a friendly heads-up, if you need to try/catch the ImportError > at some point, you'll probably want to catch SyntaxError too. They're > pretty similar in this situation, with both roughly meaning "The > module failed to load." > > -FM > > On Sun, May 16, 2010 at 11:56 PM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Mon, May 17, 2010 at 6:10 AM, cool-RR <ram.rac...@gmail.com> wrote: >>> Hello all. >>> >>> This is my first time on Django-developers. >>> >>> I remember that a few months ago, when I was doing some Django work, >>> there was something that annoyed me. I hope I'm remembering this >>> correctly, please correct me if I'm wrong. It happened sometimes that >>> the settings module in my project/app will cause an ImportError inside >>> itself. This will be caught by the `except` in the block that tries to >>> import the settings module, and this will cause it to raise another >>> ImportError saying that the settings module wasn't found or caused an >>> ImportError. This would make it difficult to understand how exactly >>> the settings module was causing the ImportError. >>> >>> Is this precise? Does this still happen? >> >> Yes, there are places where import errors get swallowed, which can >> lead to confusing or misleading stack traces. Some of these cases have >> been improved in Django 1.2, but I'm sure there are many still >> lurking. If you want to know if a specific case is still broken, >> you'll need to test that case and let us know. >> >>> Because I have just implemented something that solves this annoyance >>> for my own project, (which is unrelated to Django but also has a need >>> to import a settings module, similarly to Django.) In my solution, if >>> the settings module doesn't exist, I can get an ImportError (if I >>> wish, I can also make it fail silently), but if there's an ImportError >>> inside, I will have that error raised as itself, and not caught by my >>> logic, making it easier to debug. >>> >>> I'm basically just trying `imp.find_module` before I import. >> >> You may want to check the newly added django.utils.module_loading; >> this is a module that provides utilities for checking the existence of >> modules independently of the import proces (which was the cause of >> several of the import problems previously). >> >>> Would you have any interest in me patching Django to use this logic? >> >> We'd need to see the patch. Also, keep in mind that anything touching >> the import logic is about 5 times harder than you think it is, even >> when you take this advice into account :-) In particular, you need to >> keep in mind >> importing from eggs and importing from custom module loaders, both of >> which behave in ways that are subtly (but significantly) different to >> normal CPython module loading. The module_loading tool I mentioned >> previously expanded from a 20 line method to a 60 line method because >> of these differences. >> >> Yours, >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-develop...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > >
SyntaxError's are fairly different, if we catch one it ALWAYS means the module exists and the exception should be propagated. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
