Hacker News new | comments | show | ask | jobs | submit login
Django 1.6 beta 1 released (djangoproject.com)
129 points by Lightning 1486 days ago | hide | past | web | 69 comments | favorite

I'm currently working with Django for a client's project I'm developing. Coming off a LAMP stack binge, the technology itself has been an absolute delight. I've been given the directive to use South to manage the data model, but for future projects I was hoping somebody with more experience can give some insights as to what you've found works and what doesn't work. I'm not the biggest fan of South, but maybe it's just a lack of experience/patience.

Unfortunately that's the best we have right now. However, the guy who wrote South (and is a core Django developer) ran a Kickstarter last month to raise funds to write South-like functionality directly into the Django core.

He has been writing updates on his progress at http://www.aeracode.org/category/django-diaries/ as well, if you are curious.

for the curious: http://www.kickstarter.com/projects/andrewgodwin/schema-migr...

£17,952 pledged of £2,500 goal. So it looks like this should be happening. Stated intention as to when:

> As the intention is to get something into Django core itself, the idea is to land this for either the 1.6 or 1.7 release of Django. The work itself should be mainly completed by July 2013, and ready for alpha testing and feedback at that point for those who want to try a development version of Django.

He (Andrew Godwin) also recently gave a talk on the subject, (http://lanyrd.com/2013/djangocon-europe/schgcz/).

any idea when his talk will be published (youtube/pyvideo)?

ah, missed that, thanks.

The video was already embedded in the Lanyrd page linked to above.

I would always use South, but you need to read the migrations and _understand_ what it's doing. When it gets a conflict (and it will), you need to be able to fix up the migrations.

South is pretty great for very simplistic migrations. However, it does not issue DDL efficiently. For example, if you're adding two columns to a table, it will issue two separate ALTER TABLE statements. Depending on your database and table size, that can take twice as long as needed. It can really add up when your tables start hitting millions of records.

I saw the template support and was over the moon, so I made this:


It should help people just getting started with Django to have a smoother transition. I will add various templates with "best practices", like South included by default, stuff like that, to help both me and complete newcomers to easily get started with a new project.

I really enjoy working with Django, but in many ways, it seems to be staying pretty vanilla while other technologies head in more experimental directions. Does Django have a bright future in a world that's moving heavily client side, or will it be relegated to a relatively bland corner of the web world?

I personally hope django (and rails) keep their focus on the "bland corner of the web." The vast majority of (useful) sites out there are dead dull from a technology perspective, and I'd like tools that help me develop & deploy those types of sites as quickly as possible.

Exactly. I don't want exciting. I don't want magic. I want predictable. I want to be able to pump out high-functioning websites and add features where necessary. Let other libraries handle the bells, whistles, and doo-dads.

We've got a more complex application (Pathwright) running Django, and we're currently going much more heavy client side. Nothing about Django keeps you from doing this, and there are some excellent third party apps that actually make it very easy (django-rest-framework is awesome).

> Django have a bright future in a world that's moving heavily client side, or will it be relegated to a relatively bland corner of the web world?

This is one of those questions seeking controversy where there is none. Django seems to get out of the way even more when you shift to a heavier client.

he's probably referring to the ever-recurring topic of django not integrating front-end libs out of the box (which I in particular support).

I support that too, but I think Django should provide some default API endpoint support (like Django Rest Framework).

I'd be pretty miffed if they did this. You need only look at the comments contrib to see an example of something that was OK'ish when it was incorporated, but has languished since then. Now I question the need to even have it in contrib.

We don't have to bake components in for them to be excellent. rest-framework in particular moves ridiculously fast, and being separate from Django lets them do that. Also, if in the future something even better comes out, I can easily switch to it.

The 'comments' app has now been deprecated and will be finally removed from contrib in 1.8

Good catch, I had no idea. Glad to see this!

I'm not seeking controversy--I really enjoy Django development. It's just that I don't often hear about startups choosing to build in Django (well, besides mine), instead, going with Rails, which seems to have a more active and forward-looking developer community and more aggressive, or flashy new-school stuff like Node/Scala/Go/whatever. I guess what I'm trying to ask is, what is holding Django back? Is it just fashion, or are there more serious perceived shortcomings?

> I guess what I'm trying to ask is, what is holding Django back?

Why do you think it's being held back? I'm just not seeing the barriers in using newer tech. We stay pretty cutting edge, and haven't had any issues doing so with Django.

Because you don't hear about it growing in popularity or being used in the hot new stuff on HN.

I don't think Django is being held back at all. It's healthier than it has ever been.

Consider that the reason you don't hear about it isn't due to it not being used but instead to a cultural difference in the people who choose it. I don't think Django developers are particularly good at blogging and self-promotion compared to other projects. They communicate through mailing lists, IRC, twitter, email and documentation. I'm ok with that.

When I started my project, I evaluated a lot of different options and chose Django. One of the big factors was a cultural commitment to documentation and slow measured changes with lots of thought put into backward compatibility. Blog posts about hot startups that are using it is low on my list. (and if you do your research you will see that a surprising number of hot new startups are in fact using it)

I've seen it growing in popularity firsthand. The projects I'm involved with have seen large increases in contributors, mailing list activity, traffic on Github, downloads on PyPi over the last four or five years. PyAtl and some of the other local groups with Djangonauts in them have grown sharply over the last two years (in the Atlanta area). People from other backgrounds are more likely than ever to at least have an idea about what Django is (whereas when I was starting back in 2006 people would just stare at you).

I like playing with Go and the other newer/trendy stuff, but the thing I like about Django is that I can just sit down and get work done fast. It's not sexy, it's not clever, it's not magical, but I don't want it to be any of those things.

As a side effect of this, a huge percentage of the population is too busy getting stuff done with Django to blog and interact, aside from asking questions and getting advice. You know, like Instagram, Pinterest, NASA, National Geographic, Disqus, Mozilla, The Onion, PBS, and many more.

MTV Video use it. Yahoo use it. Django is massive, but it's like toilet paper or condoms. If you use it, you probably aren't going to blog about it because it's just doing it's job.

Plus, it's not hot new stuff, they largely attempt to make upgrading easy.

Django to me is what .Net is to C#. It's the libraries around the Python language that make it useful.

> it seems to be staying pretty vanilla

Thank God.

> Does Django have a bright future in a world that's moving heavily client side

Where are you getting the data for the client from? Django-Rest-Framework is a very convenient way to get data down into the browser layer from a DB.

I think this is an area where ASP.NET MVC excels because, while REST is nice, you also have to consider web sockets, and I have not seen good web socket support in Django, where ASP.NET has SignalR which is loads easier to configure than a custom solution with Django and Nginx/Apache. Not to mention that SignalR has very nice degradation support on both ends when web sockets are not available.

Well, if you're talking about alternatives that do asynchronism, Comet and Web Sockets well, the most convenient framework I ever used is Play 2.1

The framework is said to be reactive, meaning that you can build components that react to events asynchronously. The architecture is completely awesome, as Akka actors are baked in and the protocols are modelled with Futures and Iteratees, an FP concept for sane I/O. Things like serving unending streams of data and responding to client events using async I/O are in the very foundations of the framework, instead of being taked on later. People using Node.js or Tornado or whatever, don't know what they are missing.

See their docs on the subject:

- for Scala: http://www.playframework.com/documentation/2.1.1/ScalaAsync

- for Java: http://www.playframework.com/documentation/2.1.1/JavaAsync

I've heard it's revolutionary! How do you host Play in production?

We are using Amazon's EC2 for a huge-traffic web service (because ELB with auto-scalling has been working great for us) and Heroku for auxiliary services.

Deployment to Heroku works out of the box btw.

I mean, which web server? What is the built-in start/stage server built on? Can you place it behind Nginx?

The built-in server is Netty, a non-blocking one, and you can deploy your Play webapp as a stand-alone server, or use Nginx, Apache etc. http://www.playframework.com/documentation/2.1.1/HTTPServer

For websockets, I set the Django framework inside a Tornado thread.

By doing that I lose the wsgi functionality (you get only low level stuff, just like you'll get on java or .net), must synchronize with the normal http server with the DB (what I'll do anyway, since it's the easiest path with Django), and there is some dificulty dealing with signals (the same you'll get with java or .net). And that's all.

Or, TLDR, you lose a few features, that'll make your code resemble a bit more what you'd need to write in java or .net, but preserves most of it.

Interesting. If you have any further guidance on that I'd love to bookmark it.

There is a socket.io server for Python that claims to work with Django: https://github.com/abourget/gevent-socketio

I haven't used it personally, and would be very interested to hear others' thoughts.

EDIT: Looking through the example code ( https://github.com/abourget/gevent-socketio/tree/master/exam... ), it doesn't seem as straightforward as one might hope, especially compared to the channels API.

FWIW, I'm using the AppEngine Channels API from my Django app, and have yet to be disappointed with it.

The root of this problem is that WSGI doesn't play nicely with asynchronous stuff.

Socket.io for node.js is very awesome for stuff like that.

Have you any experience with uWSGI? Socket.io is good, but it falls back to polling AJAX.

I'm thrilled about this particular release, because it includes a significant overhaul of the way joins are built (or rather, trimmed) in the ORM and almost certainly makes your project faster if you do even relatively complex queries:

The original bug: https://code.djangoproject.com/ticket/10790

Got even worse in 1.4 https://code.djangoproject.com/ticket/18785

Thanks Anssi!

Pillow is now the preferred image manipulation library to use with Django.


I saw this earlier and am absolutely ecstatic over the new template functionality. I can't tell you how many times I've cloned old projects to start new ones, a process which isn't very fun (due to the amount of stuff one needs to change).

I started this right away: http://www.stavros.io/posts/django-template-projects/

I'll post various templates there, for example a default one containing all the "best practices" that I use (and structured that way), one that includes Persona by default (so you can just click the "Log in with Persona button" and log in), etc.

I love this feature.

Integrated connection pooling makes this release a no-brainer upgrade on release day.

Thank goodness. Not being a user of the framework, the lack of database connectivity persistence in Django was among the most surprising elements of setting up the initial test cases in our framework benchmarks project. We've since then added a Postgres test with a connection pool, but I still have the memory of that surprise from the first round.

(Incidentally, I hope to get this new version into Round 7 of our project.)

Agreed! The changes to transaction management seem pretty solid too. I've found transactions to be pretty somewhat unpredictable at times in the past, so I'm encouraged by these changes.

We're really looking forward to this. We'll still use pgbouncer, but we think we may see a slight boost.

It's not connection pooling.

Care to explain what it is?

Currently, Django closes the database connection at the end of each request/response cycle.

In 1.6, Django will optionally not do this; instead, a setting can specify the maximum amount of time to hold open and keep reusing an existing connection.

This is not connection pooling; that would imply some functionality to actively maintain and allocate connections. This is simply "your process will hold its connection open from one request/response cycle to the next".

Thanks for the detailed answer.

In what scenario can this be used?

Think of it as an optimization: Previously, each request meant a new db connection had to be opened. Now a prior connection can be reused.

It is "Persistent database connections" just like it says it is.

Persistent database connections :). Glad to see the objections finally fall by the wayside.

Still no update for the homely admin app? Would love to have it use bootstrap (or similar) to offload look and feel to those focused on it. One extra thing to do in every Django app is to change the ugly yellow on cyan title bar. I know it is already possible with apps, but then it means one more thing to fix on upgrade.

FWIW, admin2 is under active development and moving forward. I don't know if the intention is to replace the existing admin, but as it's not backwards compatible there will be some effort to upgrade if you've completed any serious customization.


I wish the admin started as an external project and stayed that way (for the sake of getting some love and attention). But of course, then we wouldn't be able to show shiny tutorial videos and people wouldn't get it automagically.

Watching this with interest.

Given its dependencies I find it highly unlikely it will find its way into the Django core anytime soon.

Is there an easy way to tell which bugs have been fixed as a part of this release?

Heh. Never would have figured out that Trac query.


This can't be right: 1.5 was just released in February. It takes at least 1 year between Django releases, right? Right!?

(He said, sarcastically.)

Seriously, it is GREAT to see the framework continue to roll forward.

There's probably a lot of stuff that didn't make the 1.5 cut.

1.5 was the first release after moving to git - they freeze the release branch and let the rest of development continue on master, so now releases will tend to be quicker (we all hope) hence the surprise with 'early' 1.6. now, since we have an alpha, 1.6 is bugfixed on branch, and 1.7 features can be developped on master like now during the 1.6 release schedule.

Christ, Django is changing too fast. I recently upgraded from 1.2 to 1.3 and it's still way obsolete.

Django 1.3 was released back in March of 2011. That's more than two years ago! Were you waiting on some sort of third party package or something?

I recently updated an older project from 1.2 to 1.5 and it was quite a bit of work.

1.3 -> 1.4 was trivial AFAIR. 1.4 -> 1.5 may need some more work if you depended a lot on function-based generic views.

I'm so excited about this .. my team just started using django on our current project after our flask experiments fall on their face

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact