Django 1.5 released

https://www.djangoproject.com/weblog/2013/feb/26/15/

by Lightning • 13 years ago

427 170 13 years ago

djangoproject.com

Lightning• 13 years ago

Release notes: https://docs.djangoproject.com/en/1.5/releases/1.5/

niggler• 13 years ago

Slightly OT: How does python2 and python3 usage numbers compare?

askedrelic2• 13 years ago

Anecdotal: I wrote a Google Reader API library in Python 2 that I'm working on porting to Python 3 and it really hasn't been that bad. I had some HTTP dependancies on urllib/urllib2 but requests (with a py3 compatibility class) made it easy.

The port was requested by someone looking to build an RSS feed reader or checker in Sublime Text 3, which using Python 3.3. Things are moving forward.

speg2• 13 years ago

Hey, that was me. Glad to hear it :)

lcc_tn• 13 years ago

So, I'll ask the noob question that has previously been getting asked to death but there's finally new reason to ask once more: someone who's had little to no prior experience with Django, and still is very much a novice with Python -- do you suggest they start using Django with Python 3 or 2?

ttruett• 13 years ago

The tipping point is getting closer but I would still recommend Python 2.X for the time being, primarily for third party support.

dmishe• 13 years ago

I would say 2 because every package out there works with it, not the case with 3 still. So it will be easier for you to follow docs and tutorials.

Plus, 2 is not going away in near future, and you'll be able to pick up 3 easily after that

pydanny3• 13 years ago

Python 3 support in Django 1.5 is experimental. I would wait until Django 1.6 is launched or there are well-known, well-working examples of Python 3 implementations of Django on high traffic sites.

jacobian5• 13 years ago

FWIW, that "experimental" label doesn't quite mean that 1.5 isn't ready for prime-time; it's more about setting community expectations. Please see my reply elsewhere in this thread (https://news.ycombinator.com/item?id=5289006) for more details.

ETA: That said, the advice to stick to Py2 right now is probably good. There's still some key missing 3rd party packages, so you'll generally be happier as a Py2 user right now.

raverbashing2• 13 years ago

Python 2

I really, really wanted to say to you Python 3, because:

- It is better (it fixes some annoyances)

- Django is working really great with it

But some things (that Django uses, but are not Django) are not working yet. Things like MySQL adaptors, South, etc

Or maybe go with Python 3 and wait for the issues to be fixed, they probably will, soon enough

whichdan• 13 years ago

Are packages not updating because it's a lot of work, or because updating will break backwards-compatibility?

billforsternz2• 13 years ago

The Python 2 v 3 conundrum seems to have been going on for an eternity. It must be putting off new adopters in their droves. For a start, you have to make an important decision about which flavor to install and how to get started right at the beginning, with no canonical right answer to the dilemma. Do the great and the good in the Python community realize how damaging this is, and how such a thing should never ever be allowed to happen again ?

baq• 13 years ago

i'd say that if you want to learn python, go with 3. if you want to build something on third party libraries while learning python at the same time, start with 2.

speg2• 13 years ago

I have been running Django 1.5 on Python 3.3 since 1.5c1 - ran into zero problems. It is solid...

but... a lot of packages are not ready for 3 yet. So it depends how far you want to go.. Playing around by yourself? I'd go with Python 3... if you need to leverage a lot of the packages you'll need to drop down to 2.7

elicox2• 13 years ago

Sorry for the Off topic, but anybody have a good experience with Appengine+Google Cloud SQL+Django?? I am thinking as alternative to AWS but I dont know if it's going to give me so much problems with the integration. Also a bit worry about the price in comparation with AWS. Anyone experience in both world?

dudeofjude• 13 years ago

not much experience but AFAIK cloud SQL is targeted for enterprise, and is far more costlier than say AWS.

mbarlow• 13 years ago

I have used both. I would strongly suggest going with AWS.

Reasons:

Local development with Appengine is pretty bad. Good luck debugging and profiling production issues.

Appengine will make you jump through many hoops that undermine or completely drop pieces of the Django framework.

Getting data out of Appengine is a huge nightmare and timesink.

If you ever decide to migrate off Appengine you will need to rewrite almost everything.

Ensorceled2• 13 years ago

This was my experience as well. I wish I had that month back.

I still have an app on GAE (the high availability version) mostly because I don't want to roll out my own HA Mongo DB. At some point it will become cost effective to do my own.

The other AWS plus: when my response time skyrockets, I can figure it out and fix it.

rattray2• 13 years ago

Was your data in the Appengine Datastore? I believe elicox was asking about using Google Cloud SQL, which I believe makes data export relatively easy (Cloud SQL is basically managed MySQL). New Django + Cloud SQL also runs basically "pure" Django, rather than the hacked-up djangoappengine of the past, so next to zero code should have to be changed in a move off AppEngine.

I recently made the switch from Datastore/djangoappengine to Cloud SQL, and it has been a far better experience.

hucker• 13 years ago

It really depends on your usecase. I've been hosting simple Django-based websites for clients (think 500-1000 uniques a day) for some years, and couldn't be happier really. There has not been a single issue, and the prices for that kind of volume is laughably low ($2-4 a week). I would NOT do django + appengine for anything complex however, since in my experience getting everything to work together without banging your head too much requires a fairly standard Django-app.

Last time I touched any of these sites other than to add security patches and the likes was 6 months ago, so it could be better/worse these days, YMMV.

old-gregg• 13 years ago

Have you looked into Rackspace Cloud? Full disclosure: I work at Rackspace, but I honestly believe that Cloud Servers + Cloud Database (hosted MySQL) at Rackspace is vastly superior choice for a reasonably large number of projects/products than AWS.

IMO, the perfect setup for most non-Facebook sized money-making web apps is nearly always dedicated SSD-powered database hardware connected to a cheap cloud of virtual boxes to serve requests. Spending engineering $$$ on scaling your data across unreliable virtual instances often is not a good idea.

Going all-dedicated, if you can afford it, is great for pretty good uptime at zero engineering cost. I recommend SoftLayer for this: they sell cheap and reliable dedicated servers connected to pretty good networks (just stay away from their older Dallas-based DCs, but DC5 is good).

rattray2• 13 years ago

While Cloud SQL and Appengine both do look expensive, I have to say the new integration is quite nice to work with. I had struggled in the past with djangoappengine, which let Django run on the weirdness of the Appengine Datastore, but now that I'm running basically "pure" Django on MySQL it's far smoother sailing. Much less setup than AWS and even easier/more straightforward than doing Django on Heroku in my opinion, but ymmv.

Docs on running native django on cloud sql: https://developers.google.com/appengine/docs/python/cloud-sq...

A guide I used to set it up: http://www.joemartaganna.com/web-development/running-django-...

friism• 13 years ago

Note that Django also works well on Heroku: https://devcenter.heroku.com/articles/django

(where I work)

streblo• 13 years ago

I'm working on a codebase that we recently ported from GAE to AWS. We ran into lots of issues with GAE, mainly around: * Exorbitant cost * Obtuse ORM * Random, unannounced/poorly reported downtime

I'm happy to elaborate, but I would stay as far away as possible from GAE. Our experience was terrible. I should note as a disclaimer that we did not use the high availability version.

danso3• 13 years ago

> Django 1.5 introduces support for a configurable User model. The basic Django User model is still around, of course, but now there's first-class support for specifying your own model and having Django's auth system make use of it.

I guess having it be a special User model is just part of the deal with Django's good out-of-the-box admin. I don't even remember how the various Rails plugins (ActiveAdmin, for example) generates the scaffolding needed for an authenticated user.

endtime• 13 years ago

Not just contrib.admin, but also contrib.auth.

It's very easy to extend the existing user model rather than creating one from scratch. I had to do some unconventional auth stuff recently and I only extended auth.User slightly (and also wrote a slightly modified authentication backend).

obviouslygreen• 13 years ago

This feature was something we'd hoped would be awesome; it's not. Going over the documentation shows there's some jaw-dropping nastiness you have to go through to make it work.

It's good that they're providing it, but I think the complexity is going to turn people off (I know I won't be using it unless it's simplified at some point in the future). User profiles have always been used for adding data to User models indirectly, and I think this is probably going to remain the best way to handle it for most uses.

joshdotsmith• 13 years ago

ActiveAdmin is actually pretty easy:

> rails generate active_admin:resource [MyModelName]

danso3• 13 years ago

Oh yes, it's easy. I was just forgetting exactly (I haven't used it in awhile) what it built out for you upon that command and what opinionated pattern it might constrain you to.

2mur• 13 years ago

The lack of a configurable User model is the reason I had to abandon django on a couple of projects. I like the framework, but formerly User was tied tightly up and down the framework (contrib.auth most notably).

bryanh4• 13 years ago

Wonderful! I just want to extend a heartfelt "thank you" to all the guys and gals contributing to Django.

Django is still a cornerstone of our startup and we're way past the point where folks have traditionally said "Django starts to constraint you". We've found that to be untrue. We love the templating, the ORM and all the built-in tools (not to mention 100s of libraries that get you an 80% finished feature in 5% of the time).

I hope to meet a lot of you at Pycon, I'd be happy to buy you a beer. I'll be wearing the bright orange Zapier shirt, you can't miss me. :-)

cookiecaper15• 13 years ago

I wonder if perhaps your people just don't have much exposure, because the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy, and most of the useful features of Django are easily available in Pyramid or Flask, yet these systems are unobtrusive and simple. Django has a monstrous "middleware" piece and a bunch of other cruft that is really just bothersome dead weight. It's not that there's no use for it, it's just that similar things are accomplished in much more concise, fast ways in other frameworks.

Not to hate on Django, jacobian, or the LJ-World, I appreciate the effort put into the system. But I don't think it really has much to offer in present-day for people developing new, serious platforms. I feel the same way about most other "full-fledged" MVC frameworks, because they all seem to far exceed what ought to be the logical bounds of their influence. In many cases you feel like you're writing Django, Cake, or Rails and not writing the actual language based on, because these frameworks mandate so much and require special integration to do much of anything. In something like Pyramid, you write Python, and Pyramid provides the pieces that make it easy to bundle together and publish as a website.

I've had positive experiences with Sinatra, too. "Microframeworks" and close cousins like Pyramid are really much more appropriate dev platforms, imo: modular, unpretentious, exist simply to help you get your program onto the web in a fast, concise, and simple way, without attempting to inject a rewrite of the standard lib or force you to conform to their unique flavor of MVC, their crappy ORM, etc.

mattdennewitz• 13 years ago

i think you are more opinionated than django

bryanh4• 13 years ago

One might easily take offense at your comment:

> perhaps your people just don't have much exposure > new, serious platforms

Both could have been omitted and your points would still have been valid.

Anyways, I'm not advocating Django as "the one true way", just stating that is hasn't hindered us in the least. :shrugs:

jtchang2• 13 years ago

For people developing new platforms I think Django has a great deal to offer and should be a serious contender if you are looking into Python based web frameworks.

A few specific things I like about Django:

1. A decent app ecosystem

2. Lots of documentation and a fairly mature codebase.

3. Django south for migrations.

philipn• 13 years ago

I develop a new, serious, widely-used platform and I love Django. I've definitely been around the block, have developed python-based web apps without frameworks, etc.

I've never had an issue with Django being inflexible. The strong conventions and the fact I don't have to make a decision about every little thing makes me, and the ecosystem, more productive.

monkeypizza• 13 years ago

I use jinja2 with django, it's good.

https://github.com/coffin/coffin/

bebop• 13 years ago

Just as a note to everyone, you can use Mako/Jinja2, SQLAlchemy and really any other Python tool/library out there with Django.

What Django does well is provide a pre-built and (IMHO) easy to use set of default tools. This does not mean that you must use these tools, they are just there by default if you need them. You could really just use Django as an HTTP routing tool.

rburhum5• 13 years ago

I built http://www.modewalk.com/ from scratch using Django. I do have "plenty of exposure", and the default template engine worked just fine. The default ORM is just fine. Most of the defaults are just fine.

Alex3917• 13 years ago

"the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy"

You can use Django with Jinja2 and SQLAlchemy.

mixmastamyk• 13 years ago

The templating is simple on purpose, to keep logic out of them. Seems like a reasonable design to me.

coldtea• 13 years ago

>I wonder if perhaps your people just don't have much exposure, because the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy, and most of the useful features of Django are easily available in Pyramid or Flask, yet these systems are unobtrusive and simple.

Define awful in concrete terms.

I've not been much constrained by Django in any way.

Even if all of those are "better" in some spec-listing way, Django could still be better by offering better integration for it's tools.

Like the iPhone, in actual use, beats phones that are better than it "spec-wise".

rbanffy• 13 years ago

While I agree with you Jinja and SQLAlchemy have nice features absent from their Django counterparts, I would not call them awful.

There are problems Django solves and problems Pyramid solves and there I nothing wrong in using one or the other.

tonyblundell• 13 years ago

The full-fledged-ness, mandates and influence that you complain about are actually plus-points for some.

run4yourlives• 13 years ago

Every time I find myself in another platform, working away, there is always a point where I stop and say to myself - I wouldn't be doing this if I was using Django.

That's why I use Django.

acdha• 13 years ago

> I wonder if perhaps your people just don't have much exposure

Having used and rejected each of the things you mentioned for various reasons, I think you're making the common mistake of assuming that other people have the same challenges and preferences you do.

It's particularly pointless to do this in a project release announcement thread – if it really doesn't work for you, just skip over it rather than flaming.

metaphorm2• 13 years ago

the only thing I agree with in your entire post is criticism of the django template language. its a pretty bad system that encourages sloppy work arounds. jinja would be nice. fortunately the template system is one of the easier things in django to swap out.

i think you're wrong about the ORM. django's ORM is actually really good, its just that the api is optimized for different use cases than SQLAlchemy. django ORM does a better job of simplifying the most common queries. its worse at complex queries. thats a reasonable trade off and i think you go way too far when you say its "awful".

zalew5• 13 years ago

> we're way past the point where folks have traditionally said "Django starts to constraint you". We've found that to be untrue. We love the templating, the ORM

Well, that means you are not past that point. First you learn to love your tools, then you learn to hate them, and it's ok.

It's not really that hard to reach the point where the orm pisses you off (examples: https://speakerdeck.com/alex/why-i-hate-the-django-orm by core dev, there is a talk somewhere on pyvideo.org), especially if you have actually written some complex sql queries in your life.

Daishiman• 13 years ago

Honestly, it's more of a 98/2 case for most business systems. Writing complex SQL for that 2% hasn't bothered me particularly thus far. And for simple (and not so simple) joins, the syntax is lighter than SQLAlchemy.

I'm not saying the critique is bad, it's just that in practice it's not something you'll be noticing day to day, and if you are, switching to pure SQL or SQLAlchemy is not a bad alternative (and Django makes that very easy to do).

Spiritus• 13 years ago

There's a lot of hype around the new configurable User module. But personally the new verbatim template tag is golden:

https://docs.djangoproject.com/en/dev/ref/templates/builtins...

jonknee2• 13 years ago

It is, but was an easy addition before. If you needed a configurable user module before you were up the creek.

message• 13 years ago

Django 1.5 unchained

Ensorceled2• 13 years ago

I hate that movie. I've never seen it but now it's the first page of search about half the time when I'm googling development issues with the real Django :-)

danso3• 13 years ago

Maybe it's Google Search biasing towards me (or at least my IP address), but Django, the framework, should be proud that it's keeping the top rank for that search term despite the buzz around Django, the movie (which, even though I love QT, was a pretty sloppy movie, IMO).

The real loser is Django Reindhardt, who Adrian Holovaty named the framework after, and is now bumped off the first page of Google results.

http://en.wikipedia.org/wiki/Django_(web_framework)#History

bradbeattie• 13 years ago

In fairness, there were a lot of other things named Django before the web framework came long: http://en.wikipedia.org/wiki/Django_(disambiguation)

barbs• 13 years ago

Dargh...beat me to it! :)

kmfrk2• 13 years ago

Looking forward to see if there'll be any SQL query improvements after I play around with the new User model and improved object fetching.

awolf• 13 years ago

>Django 1.5 is the first Django release with support for Python 3 (specifically, Python 3.2 and newer).

That sentence is of course followed by caveats about Python 3 support being experimental at this stage, but all-in-all I think this is a sign that we are finally at the tipping point for Python 3 to start gaining mainstream usage.

Thank you Django community for moving the ball forward for everyone.

jacobian5• 13 years ago

FYI, the "experimental" thing is a community thing, not really a technical judgement. Since this is our first Python 3 release, we want to have some space to make changes between 1.5 and 1.6 that we otherwise would avoid because of our strong backwards compatibility promise. The "experimental" label is about giving ourselves that room and not surprising users if there do have to be changes in the way Py3 support works between 1.5 and 1.6.

Technically, however, it's pretty rock-solid. I'll be launching a site built on Py3/1.5 is about two weeks, and aside from constantly forgetting to `print(...)` instead of `print ...` it's been surprisingly smooth sailing.

sigzero• 13 years ago

That is great to hear. I am learning with Py3 and would love to use Django with it.

SoftwareMaven4• 13 years ago

Have you found any of the third-party Django extensions to be catching up? I'm starting a new project and would love to just start with Python3, but there are a few packages I depend on: South, lxml, pytz, simplejson, requests, django-compressor, gunicorn, jinja2, twisted, txAMQP, and django-rest-framework (amongst some other utilities actually used for development).

It would sure be great to have a list of django sub-projects and their Python3 status.

Regardless, even if we start with Python2.7 and bump up to 3.3 in a few months, this is a great step!

pistacchioso2• 13 years ago

honest question: my job is programming in python. I never had python 3 installed on a machine, being it personal, a server or a computer at work. I never felt the need to. any time I wonder why I'm not using it, I go back to the "what's new" page and I remember why. I mean, the biggest change is print not being a statement anymore? Improved UTF8 is neat, and being Italian I work with not ASCII chars all the day, but even in large projects this comes down to a couple of encodings. I mean, multi-line lambdas, optional static decorators, those would justify a jump in version and backwork incompatibility, but map returning an iterator and not a list? Meh, this is good for python 2.actual_version + 1.

lutusp3• 13 years ago

> I mean, the biggest change is print not being a statement anymore?

The reasons to upgrade to Python 3 are both numerous and serious. If the only hit on your code base is to change "print this" to "print(this)", by all means upgrade. And most conversions are automated -- just run a script named "2to3":

http://docs.python.org/2/library/2to3.html

Asking why one would want to move from Python 2 to Python 3 is like asking how much a boat costs -- if you have to ask, you can't afford the consequences. Here are some of the reasons:

http://wiki.python.org/moin/Python2orPython3

A quote: "At the time of writing (July 4, 2010), the final 2.7 release is out, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active development and has already seen stable releases, such as the recent 3.2. This means that all recent standard library improvements, for example, are only available in Python 3.x."

A more complete list of the changes:

http://docs.python.org/3/whatsnew/3.0.html

Bottom line -- if you don't migrate to Python 3, over time the corner you're painting yourself into will become smaller and smaller.

jezi22• 13 years ago

Im new in django and i fell in love with it. nice update. :D

djangoguy2• 13 years ago

I'm super excited about this release but I really, really envy the Russian Doll-caching through key-based expiration and the Turbolinks of the Rails 4 release. Man I really wish django would package all the JS magic Rails comes with.

andybak• 13 years ago

Are there any mature 3rd party apps that cover this ground?

djangoguy2• 13 years ago

Not that I have found so far.

jdunck• 13 years ago

Am I correct in my understanding that the doll caching is based on .updated_at?

jimray2• 13 years ago

Hot dog.

I've been working on a small side project the past week or so using the 1.5 RC and following along the best practices recommended by 2 Scoops of Django -- https://django.2scoops.org

If you haven't already, I highly, highly recommend picking up the 2 Scoops book. It's got some great, proscriptive advice and is an easy-to-follow roadmap that helps answer a lot of "what is the right way to do this?" kinds of questions. Setting up your settings files for multiple environments, using CBV's, understanding the new User Model features, writing tests, recommended 3rd party tools, securing your setup -- these things are all a lot more clear to me.

And it's actually really well written, not just a bunch of recipes. Their explanation of mixins, for instance, is one of the clearest, most concise I've ever come across. Well worth $12 and a few hours of time to read through it.

joshschreuder3• 13 years ago

Thanks for posting about this book, I've been meaning to get into Django for a while, but I didn't find the official tutorial to be terribly enlightening beyond the basics. Plus there's a whole heap of non-code related environment stuff which I want to have best practice for too.

If anyone knows of any other good first-up books / websites (are there any interactive tutorials Treehouse / Codecademy style?), please let me know.

jimray2• 13 years ago

Fair warning: 2 Scoops definitely assumes some familiarity with how Django works, specifically models, views, templates, and forms. It won't introduce these concepts to you but will help you use them better.

The official Django Tutorial is still a great starting place for getting your head wrapped around that stuff -- https://docs.djangoproject.com/en/dev/intro/tutorial01/

danielsamuels• 13 years ago

Thanks for the book link, just got my company to purchase a copy.

AUmrysh• 13 years ago

I hope this isn't too difficult to upgrade to from 1.4 Also, I'd like to thank all of the Django contributors for their excellent work and for making my job easier!

kmfrk2• 13 years ago

Easy to upgrade: hardly. Easy to migrate. weeell ...

#django on FreeNode is pretty good, though.

tazzy531• 13 years ago

Does anyone know what the status is on the non-rel branch? It's still on 1.3.

What framework do other people using NoSQL data stores use?

bryanh4• 13 years ago

It is highly unusual to use NoSQL as the main data store in Django (so much of the built-in functionality requires relational databases, so you end up net-negative). Most Django folks augment their relational database with some NoSQL bits.

We've been big fans of storing core data in Django models, but using things like key/value stores to store random extra bits that aren't exactly core to the model. Redis is great for this, or another model as triple store style GenericRelation if you need to query on it.

I don't imagine the nonrel branch will move again, its such a departure from core Django. Look into using Flask, as there aren't many "mature" frameworks that do NoSQL core.

smnrchrds• 13 years ago

What about hstore?

dits59• 13 years ago

1.4 is work in progress

https://github.com/django-nonrel/django-1.4

lifeisstillgood• 13 years ago

Is it just me, or is it simpler to go back to wsgi middleware plain and simple?

I am getting turned off left right and centre by frameworks - Django and even Flask just make reasoning about the request/response more difficult.

Maybe I don't know how to use this but ... It would take me three months to read the new Django docs.

I am not a hater here, just wanting the simple life

DeepDuh• 13 years ago

I get this feeling about Django, but not about Flask. Its codebase is so lean I can read all the relevant parts in an hour when I want to get back into it. I don't even need docs for this thing.

However, I understand what you mean about request / response, I don't like how this is handled in most python frameworks actually, it's usually too much abstracted away.

The nicest (imperative) environment for asynchronous execution I've seen is Objective C/Cocoa for some reason. It has a way of showing you all the handles you might need, but it also makes it fairly obvious when and how these handles are called. Together with lambda support ('blocks') it's simple but effective.

I think the main difference is enterprise + closed source + well documented environments vs. opensource + not so well documented environments often originating from someone's hobby. When it comes to big middleware frameworks I prefer the first, but small lean stuff such as Flask is just fine to use IMO.

My advice is to not rely too much on the docs when you want to really know something - take a look at the source, it's all there.

naiquevin2• 13 years ago

It's great to see the Django tutorial extended to cover testing[1] and writing reusable apps[2]. These days there are quite a few Django tutorials out there covering best practices etc. (which are very good) but I would still recommend the official Poll app tutorial to any beginner because of it's simplicity.

[1] https://docs.djangoproject.com/en/1.5/intro/tutorial05/

[2] https://docs.djangoproject.com/en/1.5/intro/reusable-apps/

mkhattab• 13 years ago

Unit testing Django applications has been a source of pain for me. Writing functional or acceptances is ok using Django test client, although many recommend using WebTest, which is nice but slow if you're going to write hundreds of them.

naiquevin2• 13 years ago

I agree about the slow running time of Django tests although I have found that using sqlite database backend for tests reduces the time significantly.

wowzer• 13 years ago

On the Python 3 subject, I'd be highly interested in seeing if there any performance wins by switching your Django deployment to Python 3 over something like Python 2.7.

tshepang• 13 years ago

If you go 3.3:

* If you use decimal module, you will benefit from the serious speed improvements (http://docs.python.org/dev/whatsnew/3.3#decimal).

* The memory usage of strings is slightly lower (http://docs.python.org/3/whatsnew/3.3#performance-and-resour...).

mariuz• 13 years ago

The django-firebird (fdb driver) is now available for installing via pypi. Just run: pip install django-firebird https://pypi.python.org/pypi/django-firebird It's developed for django 1.5+

csense• 13 years ago

What do Python frameworks like Django need to do to start taking market share from Rails?

hekker• 13 years ago

Increase the price of cpu's and memory.

Django 1.5 released

Related Stories