The two big headline features, the configurable User model and Python 3 support, are both huge. The first, because as is right now, simply extending the User model feels janky and possibly broken, and the second, because Django is probably one of the biggest reasons people have not moved onto Python 3.
And Python3 is definitely my reason for not moving to Django.
Python3 became the living branch of Python during the Bush Administration. Django has been claiming ever since that there is just so much stuff in Django that, even in early 2013, they won't be able to honestly recommend it to Python3 programmers, except for "experiments".
So with this much baggage, what chance is there that Django will soon become a sleek racehorse of a Python3 framework? It could happen, or not, but I'm probably not the only one in the market for a sleek racehorse based entirely on the living branch of Python.
Django has been claiming ever since that there is just so much stuff in Django
Well, no.
There are basically two competing things that made this take a while, and which both stopped being issues right about the same time.
The first was that the initial Python 3 releases were not production-quality stuff. They worked, but they were there to let people get a feel for the changes and maybe start trying out the porting process. Anyone who just jumped to Python 3.0 shortly after release probably had no idea what they were doing (or had a very good idea what they were doing, but that group was a lot smaller).
The second was that we've got this thing, called a userbase :)
And, well, lots of 'em were running operating systems that were still shipping ancient stuff like Python 2.3, and we didn't really want to throw them under the bus, especially since it was mostly beyond their control -- a corporate department said "OK, we're going to go with RHEL", and that was that. So we waited a bit for that situation to start improving, and kicked off a process of deprecating one 2.x version each of the last few releases until, with Django 1.5, we're at a minimum of 2.6.
As for the "stopped being issues" part: Python 3.2 and especially Python 3.3 are very nice, much more mature releases than 3.0/3.1, added stuff that makes porting much less ugly, etc. etc., so suddenly running production stuff on Python 3 is really broadly viable. And, hey, we're on a minimum-2.6 stance now, and 2.6 is when the really nice porting and unified-codebase stuff got added!
Thanks for responding. This is food for thought and may be encouraging. We "just jumped on Python 3.0 shortly after release" and have been using it without a glitch for four years. I don't doubt your claim about Python 3.0's "readiness for production", though, because workstation number and text crunching "production" and high-volume web "production" are so different, but (in addition to other languages) we've been using Python3 as our only Python for years with no (known) problems.
I'd prefer to start doing webdev in Python3, too, as long as we can just work in Python3 without having our framework's (or our framework's vast, tortured userbase's) endless upgrade problems become our problems. We have no Python2 legacy baggage of our own, and I have no desire to go back and pick up anybody else's.
So when, approximately, will Django 1.6 ship, with "no reservations" about Python3 for production?
And do you have an estimate for when Django will deprecate Python2 entirely, so that Python3 programmers will become the assumed target for all features, docs, tutorials, code snippet examples, add-on modules, etc?
As a user of Django, I'd like to say thanks. This is how a framework should be built - with the users first and foremost, and with keeping support for old versions when it makes sense to do so.
I started using Django a few years ago, and still have old projects in old versions of Django. If Django would habitually "throw me under the bus", so to speak, I would quickly learn not to trust it and move to a better framework.
Django is the lagging project, actually. Most smaller projects have already bitten the bullet.
At my last Django meetup, we did a show of hands of who was waiting for Django to move before personally switching over to Python 3, and it was basically everyone.
Yep, now people will be waiting for "that Django library that doesn't work with Python 3". Hopefully those are much fewer. I'll start experimenting with 3 when 1.5 us released, I hear it's the default on ubuntu 12.10, but I might be wrong (I should check).
It's installed by default in 12.10, alongside Python 2.7. Eventually, only Python 3 will be in a default installation, but it will still use the command 'python3'.
I'm hopeful that these will be updated around the same time or moving to Python 3 won't be an option for most people. I suspect most Django apps are based on MySQL.
Most that I've encountered have been PostgreSQL or MySQL. I've seen a few sqlite3 and oracle backed sites in the wild as well. I think I've seen more redis and more mongo sites than I've seen firebird.
This pleases me greatly. No longer do I need to rely on plug-ins (and therefore, them being updated) to minimally extend the existing User model for small projects.
You could already extend the user model with a OneToOne relation plus setting in settings.py that was supported in the official Django distribution. But the way that was handled was a bit hacky so I'm glad they changed it too.
But you still were forced to use obligatory auth.User fields like username/email, etc., while there are quite a few use cases when you curse it and the only choices were either making some really weird workarounds or dropping User altogether. Russel's solution is meant to solve this problem.
If I want to create my own database and write my own SQL queries instead of using Django's object models and ORM, does it still make sense to use Django's user model in my project?
That's funny, I wanted something completely opposite: use Django's ORM in a non-web application. I have succeeded in this, thanks to the modularity of Django.
Can someone point me to a compare/contrast sort of doc between modern Django and Rails? I don't do a lot of web app programming, but I'm curious as to whether there's much of a difference between the two.
http://batsov.com/articles/2011/06/19/django-vs-rails/ appears to give a quick breakdown, but also misses some key features in my opinion. I've worked with rails for about 5 years and Django for a little over 16 months now. There's some things I do and don't like respectively for each framework.
I suggest testing each out and see which you prefer. Ruby and Python are similar languages but different enough that you'll want to spend some time learning each. Both will benefit you in the long run, as I work with ruby and python daily and is useful knowing both.
I will warn you that Django was easier for me to pick up than rails. Rails guys (me included) tout how easy it is to get going with rails, which is true. However, getting really good with rails is hard. Knowing exactly what's going on and why, how to extend ActiveModel or ActionController properly, monkey patching, proper testing practices, etc are quite the time sink, albeit a beneficial one in my opinion. I think if you have TDD or a client adamant about full test coverage, I've found rails support and practices are more flushed out than django's take.
There are two non technical differences that I think are worth knowing about. Both are good frameworks although Rails is probably quicker to get started with I suspect it may be harder to become really advanced in.
1) Stability vs Development Speed
The Rails (and it seems Ruby) attitude seems to be that fairly frequent compatibility breaking changes are OK. Bundler and a well managed Gemfile (and probably RVM too) allow you to progress at a slower rate on any Gems that haven't been updated.
The Django (and Python) world seems much more careful about not making breaking changes. In other comments this thread the slow deprecation of old Pythons in Django is mentioned. For Python itself Python 3 was I think regarded as the one chance to break things before locking down compatibility to not change very much going forwards.
2) Documentation
I find the Rails Documentation pretty poor at the details such as explaining exactly what all the valid options are and their effects. Links to the source are often given in the API docs but there are often so many layers of indirection to drill though to find what options are actually supported that the value is limited. There are plenty of examples (e.g. Railscasts) to copy and learn from to get you going on hundreds of different topics but you need these resources to guide you through the massive universe.
Django is more traditionally thoroughly documented but without the really quick 'get something running in 10 minutes' guides. I think once you get proficient you could just look up what you need and it is all there for you but there is quite a lot to learn at the start.
So in my view:
Rails - quick start, learn by examples, lean on package management systems heavily.
Django - slightly slower start, properly documented in the details, stable long term platforms.
One other BIG difference (significant enough to drive me to Rails, even though I prefer Python to Ruby), is that Rails 3.x has a lot of very nice "quality of life" features that django is lacking.
* Baked in migrations.
* The asset pipeline
Honestly those two things alone are MAJOR headache savers.
Django and Ruby 2.x are probably more or less equivalent, but Rails 3.x (and especially the upcoming 4.x, with very cool things like cache digests) are just more modern.
Sure. But, for instance, is Django as tied to the active record pattern as is Rails? And yes, I know you can swap out persistence layers in modern Rails, which is good (because active record is utter bilge), but who does that?
No, it's not. But since Rails 3 neither is rails really. Rails is more about the ActiveModel pattern, which has it's own API. Active Record inherits from ActiveModel. You can pick and choose what you want in your persistence classes, or even better, make models/classes that have no persistence layer tie.
For instance, if you want to use a class like it was a MySQL table, you could include a few ActiveModel classes which will make things for ActiveSupport helpers work with them.
Maybe I misunderstood your question. If you're looking for reasons to pick one over another, then it's whichever language you know best.
Web frameworks really only differ in philosophy, and in this case, both are batteries-included, monolithic frameworks. They are practically identical solutions.
Philosophically they're quite different. Every layer follows a different approach: templates, controllers (views in Django), urls, model definition, ORM etc. A lot of this comes from the core philosophies of the languages, whilst Ruby and Python may be closer to each other in philosophy than either are to say Java, they still have substantial differences.
We’re labeling this support “experimental” because we don’t
yet consider it production-ready, but everything’s in place
for you to start porting your apps to Python 3. Our next
release, Django 1.6, will support Python 3 without
reservations.
I haven't tested it and I might be being unfair but I have a feeling that Django's experimental non-production-ready release may be comparable to other web framework's normal production releases in terms of stability.
Although obviously plug ins and other components would also need to be compatible too.
Don't take my word for it, I'm guessing based on my impression of Django. You know some projects you want to avoid the .0 release and others are pretty safe at the beta release. I just have the feeling that Django is at the safe end. I don't have any data to back it up at this point though.
