On Fri, 2009-05-01 at 11:13 -0700, Kevin Audleman wrote:
> 
> > I can't explain any of this, but I've been thinking about your
> > question since you posted it beause I know this type of error happens
> > to me a lot (and indeed has been hard to debug), but I couldn't put my
> > finger on remembering what my solution was.  It just happened, I fixed
> > my syntax error, but still got reverseMatch error message.  Restarted
> > the server, and it was gone.
> >
> 
> Truly, Margie, this is the most inexplicable part of Django for me
> too. I'll code up a template with a bunch of {% url app.view %}
> statements which will work just fine. Then at some point I make some
> change and *bam* I've got a reverse url lookup error. The solution is
> not always obvious either. As I wrote earlier in this thread, at one
> point I suddenly had to append the app name to the names of my url's
> in urls.py. They had been working just fine, then something I changed
> made them not work.

At which point, working out "what changed" would be useful so that (a)
you can avoid it next time and (b) if it's some kind of problem in
Django, we can fix it. There is almost no magic going on in these sorts
of situations.

Certainly the error reporting from some of the URL resolving is a little
weak and that's something we're going to fix at some point. Hopefully
before 1.1 comes out. So bear with us for a little while longer on that
front and, in the interim

> 
> I agree that restarting the server is crucial. Don't know why, but it
> clears these types of things up.

Because there's a lot of internal caching going on. In particular, files
are imported once and then not imported again (since that would be
blindingly inefficient). URL configuration files are read once by each
process and the reverse lookups -- which take quite a bit of effort to
determine -- are cached so that we don't have to do the work every
single time.

It's fairly logical that if you change something you will have to tell
the code using that information that the on-disk versions have changed.
Sure, you don't have to worry about the "compile" part of a normal
development cycle when using Python very often, but there is some text
-> bytecode compilation going on, whether converting to .pyc files or
simply on the import into memory and there is other in-memory storage
taking place. The development server spoils people a bit in this
respect, in that it tries to detect a certain, fairly large class of
changes, but it cannot detect everything and isn't really a useful use
of development effort to make it do so.

> 
> Oh well, every powerful mechanism is bound to be difficult to work
> with. I figure one of these days I'll *really* understand the
> structure of a Django app and these reverse url's will no longer
> plague me.

Definitely the right attitude! :-)

The more you persist, the better you get. 

The primary audience for Django, although not very clearly defined, is
pretty much experienced programmers and web designers trying to get
things done quickly and are familiar with using it. It's a productivity
tool and time saver for doing things that you already understood. People
coming to Django as a new framework and a new programming language
(Python) and learning about HTML / Javascript / CSS and databases and
sysadmin and all the other bits and pieces are going to find there's a
lot to learn. That's only because there's a lot to learn. It's
practically impossible to write something that is both easy to learn for
people starting out and powerful enough to be a genuine aid to
experienced users and, historically, Django has been developed as an
aid, not an entry point -- which is why it's so genuinely useful in
profressional-grade products.

I have no idea what your experience is, historically, so I'm not
intending to label you here. I only want to point out that Django isn't
meant to necessarily be a shortcut to avoid understanding a broad swathe
of stuff. It can help you postpone learning about some things and gives
a nice way to learn about it, but it's an aid, not a crutch. We
obviously don't discourage people learning to use Django, Python, HTML
(insert list of stuff here...), as evidenced by this mailing list and
the IRC channel (well, setting simple good manners and patience issues
aside for now), but the implicit contract with the users is that people
starting out or at various points along the learning curve will progress
to the right, towards being more advanced users with deeper
understanding and we don't need to dumb down things to meet them on the
left side of the curve, which would harm the primary audience.

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 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to