3 ms·

What problems did you exactly run into? I hear a lot of people say this, but never get good examples, which would hopefully make the framework better.

paulgb 17y ago
The article gave some examples that I've run into myself: using email addresses instead of usernames for authentication, and adding additional fields to the User class. I also dislike the template language. Why invent your own language and control structures when everyone using it knows python? Mako (http://www.makotemplates.org/ http://www.makotemplates.org/) does a good job of not reinventing the wheel.
- mtrichardson 17y ago
  One of the main assumptions behind the Django templating language is that you don't need to know Python. http://docs.djangoproject.com/en/dev/misc/design-philosophies/#template-system http://docs.djangoproject.com/en/dev/misc/design-philosophie... "The Django template system recognizes that templates are most often written by designers, not programmers, and therefore should not assume Python knowledge." In my experience this has often been the case.
  - paulgb 17y ago
    I figured that had to do with it, but it doesn't really explain why they don't just use an equivalently powerful subset of python. Better yet, allow full python like Mako does, and let the designers decide what subset of that to use in templates.
    - racketman4 17y ago
      The template language isn't for you.
      - paulgb 17y ago
        Which is why, given the choice, I would use something more like Mako.
lacker 17y ago
One problem I often run into is that the Django libraries expect the whole application to be run by something that uses manage.py, which sets particular os.environ settings. So if you make code dependent on a Django library, often it cannot be run any more by non Django code. The eventual result is that things like cron jobs and unit testing are second-class citizens. Another problem is unicode. Current Django assumes you will deal with all strings as valid unicode, which is actually different from pre-1.0 Django. There is no way to store an arbitrary sequence of bytes without a unicode encoding. This makes perfect sense for a newspaper website, but is problematic for many other applications. Another problem is imports in general. Django does a lot of work in __init__.py files which causes problems integrating it with other systems that do a lot of things at run time.

paulgb 17y ago

The article gave some examples that I've run into myself: using email addresses instead of usernames for authentication, and adding additional fields to the User class. I also dislike the template language. Why invent your own language and control structures when everyone using it knows python? Mako (http://www.makotemplates.org/ http://www.makotemplates.org/) does a good job of not reinventing the wheel.

mtrichardson 17y ago
One of the main assumptions behind the Django templating language is that you don't need to know Python. http://docs.djangoproject.com/en/dev/misc/design-philosophies/#template-system http://docs.djangoproject.com/en/dev/misc/design-philosophie... "The Django template system recognizes that templates are most often written by designers, not programmers, and therefore should not assume Python knowledge." In my experience this has often been the case.
- paulgb 17y ago
  I figured that had to do with it, but it doesn't really explain why they don't just use an equivalently powerful subset of python. Better yet, allow full python like Mako does, and let the designers decide what subset of that to use in templates.
  - racketman4 17y ago
    The template language isn't for you.
    - paulgb 17y ago
      Which is why, given the choice, I would use something more like Mako.

lacker 17y ago

One problem I often run into is that the Django libraries expect the whole application to be run by something that uses manage.py, which sets particular os.environ settings. So if you make code dependent on a Django library, often it cannot be run any more by non Django code. The eventual result is that things like cron jobs and unit testing are second-class citizens. Another problem is unicode. Current Django assumes you will deal with all strings as valid unicode, which is actually different from pre-1.0 Django. There is no way to store an arbitrary sequence of bytes without a unicode encoding. This makes perfect sense for a newspaper website, but is problematic for many other applications. Another problem is imports in general. Django does a lot of work in __init__.py files which causes problems integrating it with other systems that do a lot of things at run time.