Hi Malcom, 2009/2/14 Malcolm Tredinnick <malc...@pointy-stick.com>: > So I realise this you are writing your opinion, but also consider that > the flip side isn't completely invalid. There's an outside chance > (alternatively expressed as "100% guaranteed") that when I write > something here about pragmatics, it's going to be based on my > experiences and collected knowledge (both professional and otherwise -- > you know, around 25 years of programming computers) and also never > intended to deceive or mislead. You're being a bit categorical in > implying that what I suggested leads to all those bad things.
OK, fair enough. Maybe I was a little too strong in my wording; most people will figure out how to fix a problem if and when it becomes an issue for them --- in that much, I agree. However, I think it's unnecessary to distract people from learning best practice by teaching them something else with the excuse of "getting started". Small projects to get started? Sure. Simple projects to get started? Sure. Projects with corners cut, though? I think that will only lead to a delayed and even steeper learning curve, when they have to unlearn things to learn something else that they could have been guided gently through from the beginning. > I know that I don't find myself "violating the DRY principle over and > over again" and I've written more than a few lines of code using Django > as one of the supporting library sets. Really? So you don't have to write your app names in your urls.py as well as in your settings.py, for instance? > It neither encourages nor discourages. Django, not being a person, is > very agnostic on the whole issue. No, as a framework and project template tool, it provides suggestions on how to start and continue a project. Those suggestions include apps that, again, have to be named on the command line, in a settings file, in a urls file (or two!), in templates, in calls to templates, etc. Don't get me wrong --- I love django, and use it joyfully over alternatives. But it's absolutely _not_ DRY, and as a result, I have to start my projects by cloning a branch of already modified templates, rather than simply using the django-admin tool's pre-supplied templates. If I wasn't doing that, then django WOULD be encouraging me to repeat myself, every time I start a project, or even an app. > We also, again, have that perspective thing going, so, in places such as > the beginner's tutorial, we might use the project name in some places, > but it's simply not that important: the idea there is to teach people > about Django That's a noble goal, and the tutorials are generally good, but again, this particular issue only distracts people from the real tasks of starting their first django project. Why do people need to learn about adding apps to the settings file right away? The boilerplate like app-loading can be autodetected, so they simply start a project, start an app, and add their models/views/templates. > not teach them about Python But they're having to learn python NOW. Obscure python, too, about how to specify module paths to load. What I'm suggesting is that it's not necessary to know (or repeat) all that just to get apps loaded. > As noted, it's not, per se, > evil to use a project-based import path, particularly for the tutorial > code, so we elect not to make a huge deal out of it. Not evil, no, but it's not best practice either. As an IT tutor, I think we fail users by teaching them to follow sketchy practices. Practices very quickly become bad habits, and its the educators job to help prevent those. Especially if they can lead to refactoring a lot of work, or re-learning things later on. > We may even change > it in the future, who knows. > Standardise what, exactly? If something's designed to be reusable, it > will be built to be installed somewhere on the Python path. That already > works. It's been standardised by following Python. Agreed, but django doesn't use the path. It expects each module to be manually specified, each template path to be manually added, etc. > This is about picking the > right battles along the learning curve. My Very First Django App or even > my fifth Django app is very unlikely to be generically useful. So > creating it as if it was is losing focus on other bits that could well > be more important at the time. This makes sense, but it's very possible to have adding django apps be fully functional and pluggable, with simple copy-and-paste to a new project. If django made it THAT easy to reuse code, then there's no reason lesson 3 or so couldn't start with, essentially, "let's start a new project, lesson3. It will combine the two earlier projects. Copy the apps from lesson1 and lesson2 to lesson3. Now run the server..." > Your lack of specifics isn't helping your communication here. What work > does Django need to build in? Granted. The problem is that I have little time to explain this all out point by point or modification by modification right now, due to workload. While I do have my modifications to startproject and startapp in version control, I switched VC systems a while back and didn't keep the history, so I'll have to diff them against the standard templates again. When I get time to do that (and take out some extra third-party apps I always use that others probably wouldn't need), I'll publish the diff on django-dev with a proper summary, and try to encourage a move towards that sort of simplicity/reusability. So, yeah... I just wanted to write a little more so it's clear I'm not just being reactionary. I greatly respect django, the developers (like yourself) who work on it, and people who help out on here. I just think django could be a little more reusable than it's been so far, and don't really understand why no one's done it before, or why the status quo is being maintained I guess, since it's my biggest django "itch" :) -- Lee --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
