On Sat, Jul 7, 2012 at 3:29 AM, Scott Woodall <scott.wood...@gmail.com> wrote: > Would there be any issues with creating a single file contains common django > modules I use, then importing that file into my views, models etc. > > Example: > > common_imports.py > =============== > from django.conf import settings > from django.core.urlresolvers import reverse > from django.shortcuts import render_to_response > .... > > > Then in any other file I need to import django stuff into, I just import my > common_imports.py > > views.py > ======= > from my_project.common_imports import * > > > This saves me from having to retype all the django imports repeatedly atop > my files. That and I can never remember the paths so I'm always hitting the > docs looking up where to import stuff from. > > I'm just looking for the downside of this pattern.
Will it work? Sure. Will it be a massive performance hit, or anything like that? No. There might be some problems with module-level state, but that's hard to predict without knowing exactly which modules you're using. However, regardless of any *technical* problems, I'd advise against it as bad engineering practice. Lets say you go down this path, and come up with whatever you consider to be a 'common subset', and put that in your common_imports list. Now a new engineer joins your project. You say you're having trouble remembering the import paths for all the Django bits; you've just put exactly the same mental load on your new team member. They need to know what is and what isn't in the common imports module. Django's import paths are common across every Django project. The contents of your "common" package isn't. So while common imports might be convenient to you, they won't necessarily be for anyone else. Django's import paths are numerous, but they are mostly sensible, so they *can* be memorised with time, and most experienced Django engineers would know the common imports really well. By adding the import abstraction, you've just made it harder (not immensely harder, but a little harder) for a random individual with experience to join your project. Now you realize that HttpNotAuthorized is something you're starting to use a lot, so you put that into your common_imports list. Except that some of your views already have HttpNotAuthorized imported. So you've got duplicated imports, and you need to do an audit of your codebase to find all the places where you've got older explicit imports of HttpNotAuthorized. Now you decide to use linting tools as part of your development stack. Your wrapped imports will make it harder for those linters to do their job, and they'll probably miss some easy-to-prevent errors. For me, it comes down to the Zen of Python. TZoP advises that explicit is better than implicit; explicitly naming each import rather than an implicit group import is a great example of this adage in practice, IMHO. Yes, this means there's a learning curve where you have to memorise the import paths for all the common Django bits; but in the long run, I don't think it will take as long to get familiar with these as you fear. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
