Hi Rich,
I'am not Django core but I think that most of your propositions are unpythonic/unkiss, unclear and way too specific or magical. I don't want to waste 10 more minutes after a startapp/startproject to think about what directory I have to remove and which files I have to repair because all those additions does not fit with my arch. There is no rules about local_settings.py (sometimes my local dispatchs live in settings.py and can deal with that :-) nor about media, static, templates (in app, in project, both or outside ?). I thing this is clearly not the way to follow and not the spirit of Python/Django. Again, Keep It Simple. Cheers, Stanislas. On Oct 19, 3:20 am, "Joe & Anne Tennies" <tenn...@gmail.com> wrote: > On Tue, Oct 18, 2011 at 5:21 PM, Rich Jones <miser...@gmail.com> wrote: > > Hey guys! > > > So I've just written a blog post about getting started with Django, > >http://gun.io/blog/python-for-the-web/, and many of the things here > > just make me think, 'why doesn't it just do that by default?' > > > Here's some of what I propose. I'm not suggesting this be a canonical > > list of features by any means, I'm just suggesting that django have > > more convenient default settings. We should look at the most common > > conventions and best practices and shape the defaults towards them. > > > Anyway, I propose that: > > > django-admin.py startproject newproj > > > should create ./static, ./uploads and ./newproj and ./newproj/ > > templates > > I personally +1 on the ./static and ./uploads. I like a starting point for > putting the static files and the uploaded files. If you don't use static > files or uploaded files, it'll never get used and deleting a folder is > pretty easy. For consistency, I'd rename ./uploads to ./media (to match the > MEDIA_ROOT notation used in settings.py). I'd also fill-in MEDIA_URL > ('/media'), MEDIA_ROOT, and STATIC_ROOT to work out of the gate. Is there a > way to statically serve the MEDIA_ROOT folder to '/media/' without > collectstatic collecting it and/or findstatic finding it by default? > > > > > in ./newproj/settings.py.. > > > import os > > TEMPLATE_DIRS = ( > > os.path.join(os.path.dirname(__file__), 'templates'), > > ) > > +1 for something to accomplish this. I personally don't care how it's done. > > > and at the end, the commonly used from local settings import * block. > > -1 'from <module> import *' should always be avoided. You never know what > can happen down the road that you may override later. > > > > > I'd also suggest that django-admin.py startproject newapp, if > > possible, add the new application to the settings.py file if it can be > > done so safely. > > -1 I can see why this seems like a good idea, but I agree that I don't want > anything touching my settings file. I also think people should learn how to > start a new app and about manage.py, startapp seems like the obvious answer > from a teaching perspective. > > > > > I would also suggest that when making a new application, the most > > commonly used imports are already there in the py files > > (render_to_response, HttpResonse, get_object_or_404, etc). > > -1 If the exception wasn't so blatently obvious and worded well in the > error, I might agree. > > > Who's with me? :) > > > R > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-developers@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. > > I also want to add another change. Put TEMPLATE_CONTEXT_PROCESSORS in the > settings.py. I would just it rather be more explicit that you may be using > these things. If there's any other settings like this that 'slide' a default > value in w/o your knowledge, I'd like it to add to the settings.py by > default. Most problems I have helping people is a default value that's not > explicitly done in the settings.py, so people don't realize it's something > they can override (or may need to). My criteria would be anything that could > require modification (within reason) when adding or removing an app to make > the app work properly. (See TEMPLATE_CONTEXT_PROCESSORS as an example.) > > -- > Joe & Anne Tennies > tenn...@gmail.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
