On Wed, Jun 15, 2011 at 11:51 AM, David Cramer <[email protected]> wrote: > This is currently a problem all over in the Django codebase, and I'd > love to see a generic/reusable approach at solving this everywhere.
We already have a generic/reusable approach -- it's just not used everywhere that it could be used. Almost all the places that we are catching ImportError, we're using it as part of an implementation of module discovery or dynamic loading. In the case of RegexURLPattern, it's the resolution of a string-based view specification to a view callable. Catching ImportError is the easiest way to establish that a named module doesn't exist, and assuming that the code is otherwise sound, it's 100% accurate. However, that's a big assumption that doesn't play out in reality, and so "couldn't import module due to error in code" errors get confused with "module does not exist" errors, leading to the confusion reported by the original message. This is a case where we need to do better at eating our own dogfood. Wherever we are using the ImportError trick to catch 'specified module does not exist', we should be using a combination of django.utils.module_loading.module_has_submodule and django.utils.importlib.import_module. Any patch implementing this pattern (wherever it occurs) would be looked upon favourably for trunk. 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
