5 ms·

Django 1.2 final out on Monday

76 points by agotterer 16y ago

MWinther 16y ago
Isn't it nice when you not only understand what an article is about from the headline, but also get all the necessary information from it alone? Short and to the point.
- hassenben 16y ago
  It is also a change from the Facebook/Steve jobs reply/ipad articles.
  - code_duck 16y ago
    The ultimate would be if Adobe's CEO used an iPad to post a message on Facebook which was leaked out because his privacy settings were changed when he wasn't looking, and then Steve Jobs replied.
    - eam 16y ago
      And then Jobs "liked" Adobe Flash, and that too got leaked.
hassenben 16y ago
Unfortunately, Django 1.2 has much more to learn from Symfony and Doctrine.
- tome 16y ago
  Would you like to share what you think those things are?
  - hassenben 16y ago
    models/ORM Doctrine does better job. - abstract model definition via yml file - multiple connections/databases/environments easily managed - Cool API (shortcuts, relations, custom tables etc.) + DQL for queries + support for multiple DB engines admin interface / CRUD interface - they are easy to generate but easier to customize under symfony. - you can do 90% of the stuff via a config file generator.yml. The rest is extending the generated code and customizing queries to the model configuration - you can do more via the config files in Symfony and control your project/applications vs Django. forms system - the abstract forms system comes with generated forms based on your model, widgets with validations, binding with your model, customizable renderers. You can have a custom CRUD interface up and running and linked to your tables in less than a few minutes. routing - routing.yml and sfPatternRouting does a much better job without using complex regex patterns - Also, all routes are abstract, understandable and well located. testing - Unit testing and functional testing is very well done. You can launch specific tests, launch failed tests only, call your model/forms easily because they are all objects, simulate a browser session etc. You can do all that stuff with Django but will a lot more code. framework vs API - symfony abstracts anything useless as a plugin where Django tends to integrate some of it in their Framework (CSV, PDF generators etc.). That's a lack of vision. Anyway, just a couple of points, I could go on and on ;-)
    - jonknee 16y ago
      So Django has a lot to learn by not having a lot of YAML config files? Its lack of YAML is actually a design goal.
    - rbanffy 16y ago
      Having read your careful answer, I have to ask: Have you ever used Django? Because all the things you say are either wrong (multiple db engines, forms for CRUD) or a matter of taste (the use of YAML, regexes for routing, including batteries). And, for the language thing, PHP is plain horrible.
      - scorpioxy 16y ago
        Agreed. Seems to me his answer is mostly taste rather than actual use. The thing about "complex regex" struck me as odd. Why are his routing regexes complex? If they're that hard to write, then I'd suggest he'd revisit the routing scheme. I haven't used Symfony before because I rather not develop in PHP unless I really have to. Having said that, If i ever have to, I'd like to give Symfony a try.
  - stevenwei 16y ago
    The original commenter might have their own thoughts, but after using both Symfony and Django here are mine: - A well organized, much more cohesive plugin structure: http://www.symfony-project.org/plugins/ http://www.symfony-project.org/plugins/ Plugins are versioned with compatibility matrices for each major Symfony release, and indexed in a centralized location. - Much better extensibility of both framework and plugin classes. You can easily subclass any existing model class to customize to your needs. Django is severely lacking here (e.g. customizing auth.User to accept an email based login without breaking existing apps that rely on auth.User). - Much better customizability of the admin interface. - Very powerful model level validation. This isn't Symfony so much as Doctrine, which is the best PHP ORM I've ever worked with. - symfony project:deploy production is pretty sweet. Of course, in general, I still prefer Django to Symfony. - PHP as a language is so unexpressive that Symfony has resorted to using YAML files and code generation to represent configuration data and model objects. - The code generation gets a bit unwieldy at times (tons of classes and empty subclasses). - Frankly, if your language is so verbose that you end up needing to store your data in a different format (e.g. YAML and PHP, XML and Java), you're using the wrong language. - Jinja2 is also a much nicer templating language than straight PHP.
    - MWinther 16y ago
      When it comes to authentication, wouldn't it be rather easy to subclass the ModelBackend class to simply use email instead of username if that's what you want? And if you want to extend user.Auth with more user data, they have a way of doing so as well, without subclassing: http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/ http://www.b-list.org/weblog/2006/jun/06/django-tips-extendi... Could you be more specific as to what kind of things the Symfony/Doctrine model level validation can do?
      - stevenwei 16y ago
        1) Yes, it is possible to subclass the ModelBackend. That's not the only step involved in switching from username based logins to email based logins, however, since the default User definition has defined a required username CharField that takes some hackery to get around. 2) Symfony does the same thing with a one to one User <-> Profile relationship. I find this to be a silly hack in both frameworks that creates extra database JOINs for no reason. If I want to place a foreign key on the user table because multiple Users can belong to a single Account, I shouldn't have to go through an additional join table. 3) You can configure Doctrine to raise an exception if you try to save() a model object with invalid fields, and check if the fields are valid at any time with isValid(). It makes a lot more sense to me to do this at the model level since there are many scenarios where you still want validation and aren't actually using forms of any sort.
- code_duck 16y ago
  One problem with both of those: PHP Also, I seriously tried to use Doctrine for a PHP project and though it seems great at first, I ended up going back to raw SQL. I have used Django and it's ORM, and I had no desire to do raw SQL. Symfony seems way over-engineered to me, and the horror of the PHP syntax really turns me off (though I'm quite familiar with PHP). If I'm going to use PHP, I'd rather just do what it is best at and get straight to the point.
maxklein 16y ago
I am pretty good at Django. But Django is really disappointing. I've switched back to PHP. These are the problems: 1. Django has a steep learning curve 2. Django speeds up the start of the project, but afterwards development gets slow. Real slow. 3. Impossible to find django programmers that are not horribly expensive 4. The django app model makes code a mess. It's a horrible model and does not create reusable code. 5. Django is instable. I have to restart my server ever minute when running Django 6. If you use something like Pinax, the amount of memory django consumes is massive 7. Your site may run fine with normal traffic, but increase to about 100 a minute and the site starts giving bad gateway errors. Be CONSISTENT in your errors, django 8. The django people are slow. It has been years and django has barely changed 9. The templating scheme cannot be outsourced. You need a programmer to understand it 10. The nifty tricks they have to render your pages with shortcuts are very difficult to understand. Really difficult to understand Django is not a nice framework. I believed in django for two years, but I've moved on. It's a good theoretical framework, but it's a terrible practical framework.
- acangiano 16y ago
  Do you use a framework with PHP?
- matclayton 16y ago
  Many sites, including us run django and cope with several 100's of requests per minute, without issue, I've never had django become unstable or a single gateway issue. How did you try and host django?
  - maxklein 16y ago
    It was a pretty low end server at webfaction. The point I'm making is that it should give me the same errors at low load that it gives at high load. But with django when you change your load, the errors change.
    - starkfist 16y ago
      Most frameworks give inconsistent errors when they tip over under high load. Almost none have been designed with truly high traffic in mind.
metamemetics 16y ago
I'm not too excited because I always use the development version of Django. Django-trunk is always surprisingly stable and hasn't given me any crashes.
- matclayton 16y ago
  same here, although I am excited about 1.2 being released as it will mark the end of the bug tracking stage, and the start of the 1.3 feature discussions.
  - metamemetics 16y ago
    True I hope drag and drop ordering for inlines is finally added so I can stop rolling my own to work with the updates, though I guess I can understand if they're hesitant to include jQueryUI in addition to jQuery in admin interface.
- rbanffy 16y ago
  Convincing a sysadmin that trunk is good enough for production is not always easy.
  - scorpioxy 16y ago
    I'd say convincing a sysadmin that any software is good enough is not always easy. Except for software that they don't have to support.
  - metamemetics 16y ago
    svn co http://code.djangoproject.com/svn/django/trunk http://code.djangoproject.com/svn/django/trunk ~/downloads/django-trunk .bash_profile: export PATH=".:~/downloads/django-trunk/django/bin:$PATH" export PYTHONPATH=~/downloads/django-trunk/
jmoiron 16y ago
I've been watching this pretty closely; the multi-db in 1.2 alone makes it worth the upgrade. It's about a 20 line backend router to get round-robin RODB usage, which is very welcome for sites under high read loads. A lot of systems have been redone to take custom XBackend classes (like the CacheBackend before it, EmailBackend and others are now available), and in my experience this is a good level of access for customizing parts of Django. Lots of applications aimed at Django are already 1.2 compatible. They've really spent a long time (a few months after freeze) making sure this release is going to be solid, so I have high hopes.
code_duck 16y ago
Well, this is good timing! We have a brand new Django project coming out next week, and I'll have time to set it up with 1.2 from the start.

76 points by agotterer 16y ago

Isn't it nice when you not only understand what an article is about from the headline, but also get all the necessary information from it alone? Short and to the point.

hassenben 16y ago
It is also a change from the Facebook/Steve jobs reply/ipad articles.
- code_duck 16y ago
  The ultimate would be if Adobe's CEO used an iPad to post a message on Facebook which was leaked out because his privacy settings were changed when he wasn't looking, and then Steve Jobs replied.
  - eam 16y ago
    And then Jobs "liked" Adobe Flash, and that too got leaked.

hassenben 16y ago

Unfortunately, Django 1.2 has much more to learn from Symfony and Doctrine.

tome 16y ago
Would you like to share what you think those things are?
- hassenben 16y ago
  models/ORM Doctrine does better job. - abstract model definition via yml file - multiple connections/databases/environments easily managed - Cool API (shortcuts, relations, custom tables etc.) + DQL for queries + support for multiple DB engines admin interface / CRUD interface - they are easy to generate but easier to customize under symfony. - you can do 90% of the stuff via a config file generator.yml. The rest is extending the generated code and customizing queries to the model configuration - you can do more via the config files in Symfony and control your project/applications vs Django. forms system - the abstract forms system comes with generated forms based on your model, widgets with validations, binding with your model, customizable renderers. You can have a custom CRUD interface up and running and linked to your tables in less than a few minutes. routing - routing.yml and sfPatternRouting does a much better job without using complex regex patterns - Also, all routes are abstract, understandable and well located. testing - Unit testing and functional testing is very well done. You can launch specific tests, launch failed tests only, call your model/forms easily because they are all objects, simulate a browser session etc. You can do all that stuff with Django but will a lot more code. framework vs API - symfony abstracts anything useless as a plugin where Django tends to integrate some of it in their Framework (CSV, PDF generators etc.). That's a lack of vision. Anyway, just a couple of points, I could go on and on ;-)
  - jonknee 16y ago
    So Django has a lot to learn by not having a lot of YAML config files? Its lack of YAML is actually a design goal.
  - rbanffy 16y ago
    Having read your careful answer, I have to ask: Have you ever used Django? Because all the things you say are either wrong (multiple db engines, forms for CRUD) or a matter of taste (the use of YAML, regexes for routing, including batteries). And, for the language thing, PHP is plain horrible.
    - scorpioxy 16y ago
      Agreed. Seems to me his answer is mostly taste rather than actual use. The thing about "complex regex" struck me as odd. Why are his routing regexes complex? If they're that hard to write, then I'd suggest he'd revisit the routing scheme. I haven't used Symfony before because I rather not develop in PHP unless I really have to. Having said that, If i ever have to, I'd like to give Symfony a try.
- stevenwei 16y ago
  The original commenter might have their own thoughts, but after using both Symfony and Django here are mine: - A well organized, much more cohesive plugin structure: http://www.symfony-project.org/plugins/ http://www.symfony-project.org/plugins/ Plugins are versioned with compatibility matrices for each major Symfony release, and indexed in a centralized location. - Much better extensibility of both framework and plugin classes. You can easily subclass any existing model class to customize to your needs. Django is severely lacking here (e.g. customizing auth.User to accept an email based login without breaking existing apps that rely on auth.User). - Much better customizability of the admin interface. - Very powerful model level validation. This isn't Symfony so much as Doctrine, which is the best PHP ORM I've ever worked with. - symfony project:deploy production is pretty sweet. Of course, in general, I still prefer Django to Symfony. - PHP as a language is so unexpressive that Symfony has resorted to using YAML files and code generation to represent configuration data and model objects. - The code generation gets a bit unwieldy at times (tons of classes and empty subclasses). - Frankly, if your language is so verbose that you end up needing to store your data in a different format (e.g. YAML and PHP, XML and Java), you're using the wrong language. - Jinja2 is also a much nicer templating language than straight PHP.
  - MWinther 16y ago
    When it comes to authentication, wouldn't it be rather easy to subclass the ModelBackend class to simply use email instead of username if that's what you want? And if you want to extend user.Auth with more user data, they have a way of doing so as well, without subclassing: http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/ http://www.b-list.org/weblog/2006/jun/06/django-tips-extendi... Could you be more specific as to what kind of things the Symfony/Doctrine model level validation can do?
    - stevenwei 16y ago
      1) Yes, it is possible to subclass the ModelBackend. That's not the only step involved in switching from username based logins to email based logins, however, since the default User definition has defined a required username CharField that takes some hackery to get around. 2) Symfony does the same thing with a one to one User <-> Profile relationship. I find this to be a silly hack in both frameworks that creates extra database JOINs for no reason. If I want to place a foreign key on the user table because multiple Users can belong to a single Account, I shouldn't have to go through an additional join table. 3) You can configure Doctrine to raise an exception if you try to save() a model object with invalid fields, and check if the fields are valid at any time with isValid(). It makes a lot more sense to me to do this at the model level since there are many scenarios where you still want validation and aren't actually using forms of any sort.
code_duck 16y ago
One problem with both of those: PHP Also, I seriously tried to use Doctrine for a PHP project and though it seems great at first, I ended up going back to raw SQL. I have used Django and it's ORM, and I had no desire to do raw SQL. Symfony seems way over-engineered to me, and the horror of the PHP syntax really turns me off (though I'm quite familiar with PHP). If I'm going to use PHP, I'd rather just do what it is best at and get straight to the point.

maxklein 16y ago

I am pretty good at Django. But Django is really disappointing. I've switched back to PHP. These are the problems: 1. Django has a steep learning curve 2. Django speeds up the start of the project, but afterwards development gets slow. Real slow. 3. Impossible to find django programmers that are not horribly expensive 4. The django app model makes code a mess. It's a horrible model and does not create reusable code. 5. Django is instable. I have to restart my server ever minute when running Django 6. If you use something like Pinax, the amount of memory django consumes is massive 7. Your site may run fine with normal traffic, but increase to about 100 a minute and the site starts giving bad gateway errors. Be CONSISTENT in your errors, django 8. The django people are slow. It has been years and django has barely changed 9. The templating scheme cannot be outsourced. You need a programmer to understand it 10. The nifty tricks they have to render your pages with shortcuts are very difficult to understand. Really difficult to understand Django is not a nice framework. I believed in django for two years, but I've moved on. It's a good theoretical framework, but it's a terrible practical framework.

acangiano 16y ago
Do you use a framework with PHP?
matclayton 16y ago
Many sites, including us run django and cope with several 100's of requests per minute, without issue, I've never had django become unstable or a single gateway issue. How did you try and host django?
- maxklein 16y ago
  It was a pretty low end server at webfaction. The point I'm making is that it should give me the same errors at low load that it gives at high load. But with django when you change your load, the errors change.
  - starkfist 16y ago
    Most frameworks give inconsistent errors when they tip over under high load. Almost none have been designed with truly high traffic in mind.

metamemetics 16y ago

I'm not too excited because I always use the development version of Django. Django-trunk is always surprisingly stable and hasn't given me any crashes.

matclayton 16y ago
same here, although I am excited about 1.2 being released as it will mark the end of the bug tracking stage, and the start of the 1.3 feature discussions.
- metamemetics 16y ago
  True I hope drag and drop ordering for inlines is finally added so I can stop rolling my own to work with the updates, though I guess I can understand if they're hesitant to include jQueryUI in addition to jQuery in admin interface.
rbanffy 16y ago
Convincing a sysadmin that trunk is good enough for production is not always easy.
- scorpioxy 16y ago
  I'd say convincing a sysadmin that any software is good enough is not always easy. Except for software that they don't have to support.
- metamemetics 16y ago
  svn co http://code.djangoproject.com/svn/django/trunk http://code.djangoproject.com/svn/django/trunk ~/downloads/django-trunk .bash_profile: export PATH=".:~/downloads/django-trunk/django/bin:$PATH" export PYTHONPATH=~/downloads/django-trunk/

jmoiron 16y ago

I've been watching this pretty closely; the multi-db in 1.2 alone makes it worth the upgrade. It's about a 20 line backend router to get round-robin RODB usage, which is very welcome for sites under high read loads. A lot of systems have been redone to take custom XBackend classes (like the CacheBackend before it, EmailBackend and others are now available), and in my experience this is a good level of access for customizing parts of Django. Lots of applications aimed at Django are already 1.2 compatible. They've really spent a long time (a few months after freeze) making sure this release is going to be solid, so I have high hopes.

code_duck 16y ago

Well, this is good timing! We have a brand new Django project coming out next week, and I'll have time to set it up with 1.2 from the start.