On Sat, 2009-02-14 at 02:11 +0000, Lee Braiden wrote: > 2009/2/14 Malcolm Tredinnick <[email protected]>: > > Fact is, there's nothing particularly wrong > > with using a project directory or even the project name, providing > > things remain within that namespace. A large portion of code that's > > written isn't going to be reusable apps > > Have to disagree here. Not only does this approach MAKE apps > non-reusable; it also violates the DRY principle over and over again, > making by-the-book django development quite tedious.
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. 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. As noted in my original post, it's a matter of perspective. > I can't imagine > why django encourages this sort of thing It neither encourages nor discourages. Django, not being a person, is very agnostic on the whole issue. Django's design principles include letting people use Python, so you can import things however you like. 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, not teach them about Python. 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. We may even change it in the future, who knows. > , when it could simply use > relative paths, like many people (including myself) have made it do > themselves quite easily. Unfortunately, with everyone fixing django > their own way, you again get the problem of non-shareable code, even > if it's reuseable in your own projects. I'd like to see django > standardise this very soon. 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. > > As far as a large portion of apps being non-reusable goes... well, how > many really unique apps do you know of online? I can't think of many > at all. There are blogs, forums, ticket systems, ecommerce systems, > front pages, comment pages, maps, wikis, catalogs, downloads/uploads, > and some other things all plugged together. Some of these have wildly > different implementations, > obviously, but generally someone who likes > a particular wiki implementation or forum implementation will want to > use it again on another site. Take away the different themes, and > there are VERY FEW truly unique apps out there. At that sort of broad categorisation level, it's easy to have a few small groups and I could broadly agree with you (although it's broad enough to not be particularly useful). Within those meta-apps, though, are many other small pieces. Again, drawing on my own experiences, which are valid, I've worked with a number of implementations of some of the above. I've also reused things where appropriate. I was not and am not advocating "write to be non-reusable". When something reaches the point of being potentially reusable, it's a matter of a few moments to check that it really is. You can either work that way from the start, or, for people just starting out, not sweat the small stuff initially and change things later. 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. > > > The best condition to be in is to understand the choices you're making > > and know why you're making them. Then you have options down the track. > > Well, no... if you make the wrong choice, then you limit your options > in future, no matter how much you understood the choice when you made > it. Trade off long-term choices for short-term gains, yes, but if > django built the work in so everyone didn't have to reproduce it, then > there would be no short-term gain to be had, by skipping that work, > since it would be already done. Your lack of specifics isn't helping your communication here. What work does Django need to build in? This thread was about import paths. Django already supports writing your import paths however you like. No extra work required. If you're talking about something other than import paths, another thread with some concrete details and a proposal (perhaps on django-dev) might well be constructive. At the moment, though, I have to admit to not really understanding what you're talking about beyond having a reaction to my permitting people to sometimes using the project name in their import paths. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
