18 ms·

Django 1.7 RC1

189 points by jsmeaton 12y ago

dits59 12y ago
Remarkable
jicea 12y ago
The big addition of the 1.7 is for me the Schema migrations (rework/improvment/integration of South http://south.aeracode.org/docs/about.html http://south.aeracode.org/docs/about.html). I really like Django, kudos to the team!
- tomjen3 12y ago
  As a potential Django user all I can scream is finally. So annoying that they didn't include those from the start.
  - raonyguimaraes 12y ago
    This is not "annoying" but actually a very hard feature to implement. You should thank Andrew for that! :D
  - zeograd 12y ago
    South was the defacto standard app to manage your schema, so it wasn't really such a bad issue. It's better to have it built in, sure, but it wasn't a nuisance before.
    - pandler 12y ago
      Other than being a little confused at first about why it wasn't included by default, using south as a separate module is about as inconvenient as using any other python package that isn't part of the standard library.
      - tragic 12y ago
        For people who know about it, yes. But probably the biggest win from pulling it into core is that, here on in, a newbie will be told to get migrating stuff from the first tutorial they do, and thus get working with this particular best practice up front. Yes, it's always been pretty hard to do django for more than 5 minutes without finding someone urging you to use South, but you never know...
arrty88 12y ago
I've always been a huge fan of Django and how productive it feels to build web apps with. In a past life my employer was 100% Microsoft ASP.NET and I wanted to migrate them to Django to save on licensing. I think the Django core is strong enough to stand up to Microsoft.
- orf 12y ago
  I used to love Django, but after using it for a couple of years I've got a bit sick of it. The template language is horrible, as is the ORM. It's only redeeming features is the forms framework (only just) and the admin panel. That being said, it's super-awesome for getting a quick demo up or starting a project with unclear requirements. Edit: Why the downvotes? The templates are slow[1] and restrictive (no function calls with parameters in templates. wat). and the ORM is utter rubbish compared to SQLAlchemy. Django shines because it is convenient (and there is a large ecosystem) - relationships are easy to configure and everything just works together. Which is nice I guess, but it does force you to use all of Django's inferior stuff. 1. http://tomforb.es/just-how-slow-are-django-templates http://tomforb.es/just-how-slow-are-django-templates
  - ekmartin 12y ago
    What do you use instead?
    - orf 12y ago
      I'm re-writing the application in Pyramid, and so far I like it. It's a bit harder to get started and get used to though.
      - secstate 12y ago
        LOL. Which is one of the huge benefits of Django, IMHO. You can slam the speed of template rendering and the ORM all you want, but in the Django tutorial the first thing you do is use the framework to model data and display it to a user. The Pyramid tutorial has you sending responses to the browser, which is so low-level I would hope the framework is more flexible than Django. EDIT: While I'm responding, I'll also note that if you're running into speed issues with your templating language, you've waited too long to setup a decent caching layer. (Hello, Varnish)
wiremine 12y ago
Kudos to the Django team! Great to see it continue to improve. Anyone know if there are any plans to update the HTML/CSS for the Admin app? Functionally it rocks, but visually it feels like you're revisiting 2001. I'd LOVE to see it rebuilt based on Zurb's Foundation or Bootstrap. I think we'd see a lot of innovation inside the admin.
- tragic 12y ago
  Grappelli[0] + django-filebrowser[1] = happiness. (Only gripe is it's not responsive.) [0] http://grappelliproject.com/ http://grappelliproject.com/ [1] https://github.com/sehmaschine/django-filebrowser https://github.com/sehmaschine/django-filebrowser
  - joeyspn 12y ago
    I always use django-admin-boostrapped for my django projects... https://github.com/django-admin-bootstrapped/django-admin-bootstrapped https://github.com/django-admin-bootstrapped/django-admin-bo...
  - bradleyg_ 12y ago
    http://djangosuit.com http://djangosuit.com is another great one. Would love to see an updated default though.
- collyw 12y ago
  There is at least one bootstrap application for it to make it look a bit more modern.
- webjunkie 12y ago
  I would be very much in favor for at least updating to some CSS3 features and refreshing the experience. Tweak some colors and borders here and there, no total overhaul needed.
- andybak 12y ago
  Because we want to maintain compatibility with 3rd party admin extensions which often depend on the specific markup, we've had a lot of luck with CSS-only reskinning. The markup really isn't terrible so we've made sure no Django CSS is loaded (just create 0 byte CSS files matching each built in CSS file). We then add in Bootstrap CSS+JS so we can some of the handy UI components and then our own CSS on top of that.
yuvadam 12y ago
The 1.7 release is another great upgrade to the solid Django ecosystem. Personally I am very much looking forward to native migrations (another step forward from South, which by itself was awesome) as well as some of the new custom QuerySet and Manager functionality. That said, there seems to be a slight hiccup in third-party apps moving towards 1.7, since those that have existing South migrations are in the dilemma of whether to break backwards compatibility in moving to the native migrations framework. Also there is a nice chunk of deprecated APIs (such as @transaction.atomic) that many projects will throw warnings about now, until those are patched. Personaly, I've already started migrating projects to 1.7 in anticipation of an upcoming release in the next few weeks. Kudos!
- avidal 12y ago
  Where do you see that @transaction.atomic is deprecated? It's not in the release notes[1] and if I recall correctly, was only introduced in 1.6 as a means to come up with a consistent API for nested transactions and savepoints. Are you implying that it's deprecated as a decorator? Even if that's the case, I still can't find a source. [1] https://docs.djangoproject.com/en/dev/releases/1.7/ https://docs.djangoproject.com/en/dev/releases/1.7/
  - yuvadam 12y ago
    Oops, I meant that commit_on_success() is deprecated in favor of atomic().
dudus 12y ago
Unfortunately AppEngine only includes django up to 1.5 I don't know why they take so long to update their Third Party libs. Of course you can include the lib yourself in the project but that's a burden specially with large apps because you get restricted by the number of files you can upload, so adding large libs is not the best world. https://developers.google.com/appengine/docs/python/tools/libraries27 https://developers.google.com/appengine/docs/python/tools/li...
channikhabra 12y ago
Where do Django stand in the js everywhere fortresses of MEAN and damn awesome stuff like meteor/derby? I mean it's possible to use django with client-side js, precompiling js templates server side and using Django as REST backend or use websockets layer on it and do stuff the modern apps should (arguably) be doing i.e refresh-less UX, fast native-like apps, but still these major server-side frameworks (django, ror and friends) are so much loved and used by vast majority of "pros". Most likely I am living in a bubble that making apps same language both sides specially in frameworks like Meteor which revolutionises the workflow is the best way to go. Please break my bubble and enlighten me why we should still be using these framweworks and not js only alternatives. I don't mean to start a flame war (or may be I do), I just want my perspective changed. It is sitting pretty stubbornly in my head that meteor like start-to-end pipelined flows are the way to go (read all-sides javascript frameworks).
- lmm 12y ago
  If you find using the same language in the browser and the server to be a compelling advantage, js is your only option. But IME it's not actually that big an advantage; most logic code belongs to one layer or another. For domain objects (i.e. non-logic code) you can use something like protocol buffers and then you can use the same object definition in both languages. Advantages to me would be much more mature ORM support (e.g. others are talking about how good the migrations are; there are some cool efforts in js e.g. Knex but they're still very primitive in comparison to what Django can now do automatically), better templating (certainly arguable, but I find none of the js approaches encourage proper separation of markup and logic), and a much more comfortable language for writing business logic in. Python has nowhere near as many "gotchas" as js, and is much more readable for a less-technical domain expert.
  - emidln 12y ago
    You can easily do this with Clojure/ClojureScript too. As I understand it, it's also possible with Haxe. Theoretically, you could do the same with Ruby or Scala too (not sure I've heard of other languages with reasonably complete implementations that can handle both compile to native code (or a fast interpreter) and compile to javascript).
gitaarik 12y ago
I've been using the Django dev version (1.8) for a personal project for a while now. I really like the built in migration framework, which is available from this release (1.7). I think it's even easier and cleaner than South! Also the documentation is very clear (as always). There's just two commands [0]: makemigrations - to create migrations migrate - to (un)apply migrations Adding migrations to an existing app is just running the `makemigrations` command for that app [1]: python manage.py makemigrations your_app_label It will create a migrations/ folder in the app folder and you're good to go. When you change your models and run `makemigrations` again, it will make migrations for the changes you made and you can apply them with the `migrate` command. For migrations that can't be detected automatically (like renaming models/fields) you can create an empty migration file (by supplying `--empty` to the `makemigrations` command) and edit the migration file yourself. With the great documentation this is easily done [2]. They also support data migrations (migration for the data in your database instead of the scheme of the tables). So I think it replaces pretty much all features of South. BTW, the original creator of South (Andrew Godwin) helped create the migration framework in Django, so no hard feelings ;). [0] https://docs.djangoproject.com/en/1.7/topics/migrations/#two-commands https://docs.djangoproject.com/en/1.7/topics/migrations/#two... [1] https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-migrations-to-apps https://docs.djangoproject.com/en/1.7/topics/migrations/#add... [2] https://docs.djangoproject.com/en/1.7/ref/migration-operations/ https://docs.djangoproject.com/en/1.7/ref/migration-operatio...
joeyspn 12y ago
Do you think the upgrade from 1.6+south to 1.7 will be painful for small crud projects? Can't wait to update to the 1.7 final version...
- rajivm 12y ago
  Not unless you run into a library incompatibility with Django 1.7 (specifically, custom FileField's come to mind). If you have few dependencies other than Django, the upgrade from South should be fairly smooth. You essentially start your migrations from scratch: Delete the South ones, let Django re-generate migration 0.
skizm 12y ago
I with Django would add the south project to their core. It seems like an enormous oversight that you can't change data models after you sync them to the DB for the first time without deleting all the data or using a 3rd party app (south). EDIT: I need to read things more carefully. My bad. Good job Django.
- simonpantzare 12y ago
  That is one of the big things Django 1.7. "There's a new built-in schema-migration framework."
  - tragic 12y ago
    Seriously. They even made a t-shirt[1] punning on it. [1] http://teespring.com/django17-v2 http://teespring.com/django17-v2
    - revo13 12y ago
      Aw man... Where can I get this now that the campaign has ended?
      - tragic 12y ago
        As I understand it, the smallest run they can do is 20. So if you can find 19 other people who missed out, they could run another campaign. I'd guess Russell Keith Magee or someone else from the DSF would be the one to bother about it.
        randlet 12y ago
        I bought one but ordered too small a size so I'd be in for purchasing another if someone were to make this happen. It's a nice shirt and I want one that fits!
        freakboy3742 12y ago
        I'll save you the suspense - we've run the campaign twice, and we're not going to run it again. Part of the sales gimmick was that it was the limited availability. But, fear not - given the success of the campaign this time, I think it's fair to say that when the time comes, there will be a Django 1.8 release shirt.
sprite 12y ago
A bit offtopic, but I was wondering what some good books/resources for learning django are? I've mostly been using rails or sinatra for web stuff, but planning on doing a project that I want to host on GAE and write with django and django rest framework. A friend recommended: http://www.amazon.com/Two-Scoops-Django-Best-Practices/dp/098146730X/ref=sr_1_1?s=books&ie=UTF8&qid=1403886617&sr=1-1&keywords=django http://www.amazon.com/Two-Scoops-Django-Best-Practices/dp/09... but looking for other recommendations as well.
- bad_user 12y ago
  The documentation is like a book. Start with the tutorial: https://docs.djangoproject.com/en/1.6/ https://docs.djangoproject.com/en/1.6/
- softinio 12y ago
  Do not use Django with GAE. Really pointless to do this. You are better off with Frameworks like Flask with GAE in my experience. To get the full benefit of Django you really need to avoid GAE in my opinion
  - sprite 12y ago
    How come?
    - andrewfong 12y ago
      The big issue is that Django's ORM is built around traditional relational databases, while Google App Engine is not. You can certainly make the two work well enough together if you know what you're doing, but for someone just getting started, it's an unnecessary exercise in frustration. If you want to use GAE, I recommend just starting with web.py or whatever is the default framework there. It's fairly easy to learn. If you need a place to host Django, a good chunk of the Django documentation is dedicated to discussing how to do that. There's also Heroku and what not as well.
      - sprite 12y ago
chdir 12y ago
If I were to summarize Django: it's a godsend for new comers (the whole package is fabulous & comprehensive with excellent documentation). It'll get you to your destination fast & in style. But very soon, as you start getting a hang of it, you'll realize that it's rigidity is wearing you out. I wish there's a django-light fork that takes all the good things in it and mashes it with jinja2 & SQLAlchemy. Please make it a lot more modular. Maybe a kickstarter (like South did & Postgres improvement is doing) P.S. I know there's flask, but it's still a while before it reaches that point for some of us.
- jpulec 12y ago
  More modular? I think how modular it is, is one of Django's greatest strengths. Don't like django's templating? You can be up and running with jinja2 in less than 20 lines. Don't like Django's user model? Substitute your own, or if you just need a different auth backend, write your own. Have a desire to use a less common DB? Write a db backend. As far as trashing the ORM for SQLAlchemy, there are a number of django packages that aim to do just that. There is a small number of ways I could imagine Django being MORE modular.
- secstate 12y ago
  I'm pretty sure Flask is as robust as it's going to be. Flask is Django without all the batteries included, which is what you're asking for. Throw Jinja2 templates in there and SQLAlchemy for an ORM and that's exactly what you're after. Now, if you want views and middleware too, well that's core Django and you probably want django as well. What parts of it see too rigid to you?
- fdemmer 12y ago
  here are jacob and jacob on "django minus django": https://www.youtube.com/watch?v=aFRH-oHcbn8 https://www.youtube.com/watch?v=aFRH-oHcbn8 slides: https://speakerdeck.com/jacobian/django-minus-django-djangocon-eu-2014 https://speakerdeck.com/jacobian/django-minus-django-djangoc... if you take time to really look into it, it's pretty modular...
- mahmoudimus 12y ago
  One common theme I'm hearing is that individuals want a "way to grow big" but with the ease of getting started quickly while having an extensive ecosystem. Flask was written on top of Werkzeug as an example of how to build a "roll-your-own" web framework. It has a few shortcomings, but overall, it's OK and you can contour it to whatever you need done. After all, if Flask starts to "wear you out," you can always graduate to just Werkzeug. I think there's an opportunity here for something like this to be built on top of Pyramid, which I've found to have a very extensible API. The main problem with Pyramid is the perception to newcomers - there is more than one way to do it and it doesn't have any opinions on how you should go about doing something. It leaves it up to your imagination. There's a slight trade off here between an opinionated framework and the extensibility of Pyramid.
softinio 12y ago
Loving the built in migrations with Django 1.7 inconjunction with builtin virtualenv stuff with Python 3.4 :-)
- rectangletangle 12y ago
  I love Python's batteries included philosophy. It's nice not to require 500+ dependencies just to write a simple fizzbuzz. It's really nice to see Django take this to heart.

189 points by jsmeaton 12y ago

Remarkable

jicea 12y ago

The big addition of the 1.7 is for me the Schema migrations (rework/improvment/integration of South http://south.aeracode.org/docs/about.html http://south.aeracode.org/docs/about.html). I really like Django, kudos to the team!

tomjen3 12y ago
As a potential Django user all I can scream is finally. So annoying that they didn't include those from the start.
- raonyguimaraes 12y ago
  This is not "annoying" but actually a very hard feature to implement. You should thank Andrew for that! :D
- zeograd 12y ago
  South was the defacto standard app to manage your schema, so it wasn't really such a bad issue. It's better to have it built in, sure, but it wasn't a nuisance before.
  - pandler 12y ago
    Other than being a little confused at first about why it wasn't included by default, using south as a separate module is about as inconvenient as using any other python package that isn't part of the standard library.
    - tragic 12y ago
      For people who know about it, yes. But probably the biggest win from pulling it into core is that, here on in, a newbie will be told to get migrating stuff from the first tutorial they do, and thus get working with this particular best practice up front. Yes, it's always been pretty hard to do django for more than 5 minutes without finding someone urging you to use South, but you never know...

arrty88 12y ago

I've always been a huge fan of Django and how productive it feels to build web apps with. In a past life my employer was 100% Microsoft ASP.NET and I wanted to migrate them to Django to save on licensing. I think the Django core is strong enough to stand up to Microsoft.

orf 12y ago
I used to love Django, but after using it for a couple of years I've got a bit sick of it. The template language is horrible, as is the ORM. It's only redeeming features is the forms framework (only just) and the admin panel. That being said, it's super-awesome for getting a quick demo up or starting a project with unclear requirements. Edit: Why the downvotes? The templates are slow[1] and restrictive (no function calls with parameters in templates. wat). and the ORM is utter rubbish compared to SQLAlchemy. Django shines because it is convenient (and there is a large ecosystem) - relationships are easy to configure and everything just works together. Which is nice I guess, but it does force you to use all of Django's inferior stuff. 1. http://tomforb.es/just-how-slow-are-django-templates http://tomforb.es/just-how-slow-are-django-templates
- ekmartin 12y ago
  What do you use instead?
  - orf 12y ago
    I'm re-writing the application in Pyramid, and so far I like it. It's a bit harder to get started and get used to though.
    - secstate 12y ago
      LOL. Which is one of the huge benefits of Django, IMHO. You can slam the speed of template rendering and the ORM all you want, but in the Django tutorial the first thing you do is use the framework to model data and display it to a user. The Pyramid tutorial has you sending responses to the browser, which is so low-level I would hope the framework is more flexible than Django. EDIT: While I'm responding, I'll also note that if you're running into speed issues with your templating language, you've waited too long to setup a decent caching layer. (Hello, Varnish)

wiremine 12y ago

Kudos to the Django team! Great to see it continue to improve. Anyone know if there are any plans to update the HTML/CSS for the Admin app? Functionally it rocks, but visually it feels like you're revisiting 2001. I'd LOVE to see it rebuilt based on Zurb's Foundation or Bootstrap. I think we'd see a lot of innovation inside the admin.

tragic 12y ago
Grappelli[0] + django-filebrowser[1] = happiness. (Only gripe is it's not responsive.) [0] http://grappelliproject.com/ http://grappelliproject.com/ [1] https://github.com/sehmaschine/django-filebrowser https://github.com/sehmaschine/django-filebrowser
- joeyspn 12y ago
  I always use django-admin-boostrapped for my django projects... https://github.com/django-admin-bootstrapped/django-admin-bootstrapped https://github.com/django-admin-bootstrapped/django-admin-bo...
- bradleyg_ 12y ago
  http://djangosuit.com http://djangosuit.com is another great one. Would love to see an updated default though.
collyw 12y ago
There is at least one bootstrap application for it to make it look a bit more modern.
webjunkie 12y ago
I would be very much in favor for at least updating to some CSS3 features and refreshing the experience. Tweak some colors and borders here and there, no total overhaul needed.
andybak 12y ago
Because we want to maintain compatibility with 3rd party admin extensions which often depend on the specific markup, we've had a lot of luck with CSS-only reskinning. The markup really isn't terrible so we've made sure no Django CSS is loaded (just create 0 byte CSS files matching each built in CSS file). We then add in Bootstrap CSS+JS so we can some of the handy UI components and then our own CSS on top of that.

yuvadam 12y ago

The 1.7 release is another great upgrade to the solid Django ecosystem. Personally I am very much looking forward to native migrations (another step forward from South, which by itself was awesome) as well as some of the new custom QuerySet and Manager functionality. That said, there seems to be a slight hiccup in third-party apps moving towards 1.7, since those that have existing South migrations are in the dilemma of whether to break backwards compatibility in moving to the native migrations framework. Also there is a nice chunk of deprecated APIs (such as @transaction.atomic) that many projects will throw warnings about now, until those are patched. Personaly, I've already started migrating projects to 1.7 in anticipation of an upcoming release in the next few weeks. Kudos!

avidal 12y ago
Where do you see that @transaction.atomic is deprecated? It's not in the release notes[1] and if I recall correctly, was only introduced in 1.6 as a means to come up with a consistent API for nested transactions and savepoints. Are you implying that it's deprecated as a decorator? Even if that's the case, I still can't find a source. [1] https://docs.djangoproject.com/en/dev/releases/1.7/ https://docs.djangoproject.com/en/dev/releases/1.7/
- yuvadam 12y ago
  Oops, I meant that commit_on_success() is deprecated in favor of atomic().

dudus 12y ago

Unfortunately AppEngine only includes django up to 1.5 I don't know why they take so long to update their Third Party libs. Of course you can include the lib yourself in the project but that's a burden specially with large apps because you get restricted by the number of files you can upload, so adding large libs is not the best world. https://developers.google.com/appengine/docs/python/tools/libraries27 https://developers.google.com/appengine/docs/python/tools/li...

channikhabra 12y ago

Where do Django stand in the js everywhere fortresses of MEAN and damn awesome stuff like meteor/derby? I mean it's possible to use django with client-side js, precompiling js templates server side and using Django as REST backend or use websockets layer on it and do stuff the modern apps should (arguably) be doing i.e refresh-less UX, fast native-like apps, but still these major server-side frameworks (django, ror and friends) are so much loved and used by vast majority of "pros". Most likely I am living in a bubble that making apps same language both sides specially in frameworks like Meteor which revolutionises the workflow is the best way to go. Please break my bubble and enlighten me why we should still be using these framweworks and not js only alternatives. I don't mean to start a flame war (or may be I do), I just want my perspective changed. It is sitting pretty stubbornly in my head that meteor like start-to-end pipelined flows are the way to go (read all-sides javascript frameworks).

lmm 12y ago
If you find using the same language in the browser and the server to be a compelling advantage, js is your only option. But IME it's not actually that big an advantage; most logic code belongs to one layer or another. For domain objects (i.e. non-logic code) you can use something like protocol buffers and then you can use the same object definition in both languages. Advantages to me would be much more mature ORM support (e.g. others are talking about how good the migrations are; there are some cool efforts in js e.g. Knex but they're still very primitive in comparison to what Django can now do automatically), better templating (certainly arguable, but I find none of the js approaches encourage proper separation of markup and logic), and a much more comfortable language for writing business logic in. Python has nowhere near as many "gotchas" as js, and is much more readable for a less-technical domain expert.
- emidln 12y ago
  You can easily do this with Clojure/ClojureScript too. As I understand it, it's also possible with Haxe. Theoretically, you could do the same with Ruby or Scala too (not sure I've heard of other languages with reasonably complete implementations that can handle both compile to native code (or a fast interpreter) and compile to javascript).

gitaarik 12y ago

I've been using the Django dev version (1.8) for a personal project for a while now. I really like the built in migration framework, which is available from this release (1.7). I think it's even easier and cleaner than South! Also the documentation is very clear (as always). There's just two commands [0]: makemigrations - to create migrations migrate - to (un)apply migrations Adding migrations to an existing app is just running the `makemigrations` command for that app [1]: python manage.py makemigrations your_app_label It will create a migrations/ folder in the app folder and you're good to go. When you change your models and run `makemigrations` again, it will make migrations for the changes you made and you can apply them with the `migrate` command. For migrations that can't be detected automatically (like renaming models/fields) you can create an empty migration file (by supplying `--empty` to the `makemigrations` command) and edit the migration file yourself. With the great documentation this is easily done [2]. They also support data migrations (migration for the data in your database instead of the scheme of the tables). So I think it replaces pretty much all features of South. BTW, the original creator of South (Andrew Godwin) helped create the migration framework in Django, so no hard feelings ;). [0] https://docs.djangoproject.com/en/1.7/topics/migrations/#two-commands https://docs.djangoproject.com/en/1.7/topics/migrations/#two... [1] https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-migrations-to-apps https://docs.djangoproject.com/en/1.7/topics/migrations/#add... [2] https://docs.djangoproject.com/en/1.7/ref/migration-operations/ https://docs.djangoproject.com/en/1.7/ref/migration-operatio...

joeyspn 12y ago

Do you think the upgrade from 1.6+south to 1.7 will be painful for small crud projects? Can't wait to update to the 1.7 final version...

rajivm 12y ago
Not unless you run into a library incompatibility with Django 1.7 (specifically, custom FileField's come to mind). If you have few dependencies other than Django, the upgrade from South should be fairly smooth. You essentially start your migrations from scratch: Delete the South ones, let Django re-generate migration 0.

skizm 12y ago

I with Django would add the south project to their core. It seems like an enormous oversight that you can't change data models after you sync them to the DB for the first time without deleting all the data or using a 3rd party app (south). EDIT: I need to read things more carefully. My bad. Good job Django.

simonpantzare 12y ago
That is one of the big things Django 1.7. "There's a new built-in schema-migration framework."
- tragic 12y ago
  Seriously. They even made a t-shirt[1] punning on it. [1] http://teespring.com/django17-v2 http://teespring.com/django17-v2
  - revo13 12y ago
    Aw man... Where can I get this now that the campaign has ended?
    - tragic 12y ago
      As I understand it, the smallest run they can do is 20. So if you can find 19 other people who missed out, they could run another campaign. I'd guess Russell Keith Magee or someone else from the DSF would be the one to bother about it.
      - randlet 12y ago
        I bought one but ordered too small a size so I'd be in for purchasing another if someone were to make this happen. It's a nice shirt and I want one that fits!
      - freakboy3742 12y ago
        I'll save you the suspense - we've run the campaign twice, and we're not going to run it again. Part of the sales gimmick was that it was the limited availability. But, fear not - given the success of the campaign this time, I think it's fair to say that when the time comes, there will be a Django 1.8 release shirt.

sprite 12y ago

A bit offtopic, but I was wondering what some good books/resources for learning django are? I've mostly been using rails or sinatra for web stuff, but planning on doing a project that I want to host on GAE and write with django and django rest framework. A friend recommended: http://www.amazon.com/Two-Scoops-Django-Best-Practices/dp/098146730X/ref=sr_1_1?s=books&ie=UTF8&qid=1403886617&sr=1-1&keywords=django http://www.amazon.com/Two-Scoops-Django-Best-Practices/dp/09... but looking for other recommendations as well.

bad_user 12y ago
The documentation is like a book. Start with the tutorial: https://docs.djangoproject.com/en/1.6/ https://docs.djangoproject.com/en/1.6/
softinio 12y ago
Do not use Django with GAE. Really pointless to do this. You are better off with Frameworks like Flask with GAE in my experience. To get the full benefit of Django you really need to avoid GAE in my opinion
- sprite 12y ago
  How come?
  - andrewfong 12y ago
    The big issue is that Django's ORM is built around traditional relational databases, while Google App Engine is not. You can certainly make the two work well enough together if you know what you're doing, but for someone just getting started, it's an unnecessary exercise in frustration. If you want to use GAE, I recommend just starting with web.py or whatever is the default framework there. It's fairly easy to learn. If you need a place to host Django, a good chunk of the Django documentation is dedicated to discussing how to do that. There's also Heroku and what not as well.
    - sprite 12y ago

chdir 12y ago

If I were to summarize Django: it's a godsend for new comers (the whole package is fabulous & comprehensive with excellent documentation). It'll get you to your destination fast & in style. But very soon, as you start getting a hang of it, you'll realize that it's rigidity is wearing you out. I wish there's a django-light fork that takes all the good things in it and mashes it with jinja2 & SQLAlchemy. Please make it a lot more modular. Maybe a kickstarter (like South did & Postgres improvement is doing) P.S. I know there's flask, but it's still a while before it reaches that point for some of us.

jpulec 12y ago
More modular? I think how modular it is, is one of Django's greatest strengths. Don't like django's templating? You can be up and running with jinja2 in less than 20 lines. Don't like Django's user model? Substitute your own, or if you just need a different auth backend, write your own. Have a desire to use a less common DB? Write a db backend. As far as trashing the ORM for SQLAlchemy, there are a number of django packages that aim to do just that. There is a small number of ways I could imagine Django being MORE modular.
secstate 12y ago
I'm pretty sure Flask is as robust as it's going to be. Flask is Django without all the batteries included, which is what you're asking for. Throw Jinja2 templates in there and SQLAlchemy for an ORM and that's exactly what you're after. Now, if you want views and middleware too, well that's core Django and you probably want django as well. What parts of it see too rigid to you?
fdemmer 12y ago
here are jacob and jacob on "django minus django": https://www.youtube.com/watch?v=aFRH-oHcbn8 https://www.youtube.com/watch?v=aFRH-oHcbn8 slides: https://speakerdeck.com/jacobian/django-minus-django-djangocon-eu-2014 https://speakerdeck.com/jacobian/django-minus-django-djangoc... if you take time to really look into it, it's pretty modular...
mahmoudimus 12y ago
One common theme I'm hearing is that individuals want a "way to grow big" but with the ease of getting started quickly while having an extensive ecosystem. Flask was written on top of Werkzeug as an example of how to build a "roll-your-own" web framework. It has a few shortcomings, but overall, it's OK and you can contour it to whatever you need done. After all, if Flask starts to "wear you out," you can always graduate to just Werkzeug. I think there's an opportunity here for something like this to be built on top of Pyramid, which I've found to have a very extensible API. The main problem with Pyramid is the perception to newcomers - there is more than one way to do it and it doesn't have any opinions on how you should go about doing something. It leaves it up to your imagination. There's a slight trade off here between an opinionated framework and the extensibility of Pyramid.

softinio 12y ago

Loving the built in migrations with Django 1.7 inconjunction with builtin virtualenv stuff with Python 3.4 :-)

rectangletangle 12y ago
I love Python's batteries included philosophy. It's nice not to require 500+ dependencies just to write a simple fizzbuzz. It's really nice to see Django take this to heart.