Django 1.3 vs Rails 3: A not so final showdown
batsov.com
batsov.com
Python 3 has not "replaced" Python 2. The reality is quite a bit more nuanced than this, and it is hardly a bad thing that Django does not support Python 3 right now. To give this section the heading of "The great divide" is just a tiny bit hyperbolic.
From the top of the python.org page dedicated to the subject[1]:
Python 2.x is the status quo, Python 3.x is the shiny new thing
Also from that same page, here are some of the key things in Python 3 that are not in Python 2 yet:
* function annotations
* syntax for keyword-only arguments
* extended tuple unpacking
* non-local variable declarations
There is nothing in this list that a developer must have in order to develop their app, and there are no Python 3 exclusive projects that do not work with Python 2.
The fact that few major Python projects are currently ported to Python 3 is not evidence of some tremendous looming problem in the Python language. It is evidence that Python 3 is only, really, an evolutionary transition from Python 2 and that this transition has a long time horizon.
The move from Python 2 to Python 3 is nothing like the move from Ruby 1.8 to Ruby 1.9. There are no dramatic speed or stability improvements that make Python 3 something that is terrible to miss out on, and there is no rush to get projects ported to Python 3. It will happen when it happens.
You let the package manager manage whatever you are not very interested in (something you don't care with recent version you are running). I'd never let it manage something I can manage better.
http://guide.python-distribute.org/introduction.html#current...
http://tarekziade.wordpress.com/2010/02/10/pep-345-and-386-a...
It's confusing but improving quickly. I know it took me quite a while to figure out what the right way to do things in python was.
This is also where rails' conventions help. As good as people say the documentation for Django is, many searches pull up blog posts from 2006 which were right for their time but now are simply outdated. That being said, I think there has been a tremendous boost in Django activity in the past year or so. I feel like they are getting in front of the curve again.
I recently started getting hot and heavy with Linux after moving my stuff to EC2. I thought package managers were the bee's knees until I realised that my production server and my development box (at home) we're running drastically different versions of the same program/library. This of course caused a whole bunch of incompatibility problems and headaches when it came to building other stuff.
If you care about versions and stability, it's just safer and more reliable to compile from source that you know that works. Package managers can sometimes be a crap shoot.
Installing from tar.gz isn't at all complex or difficult, either. The article would have been much more helpful if the author knew more about Python and Django.
Source: http://packages.ubuntu.com/search?keywords=python-django
I think Rails is slightly more beginner friendly because of the conventions and magic but that becomes frustrating for more advanced developers. Rails is working on making themselves more customizable and Django is working on codifying standards. I'm pretty sure it's a meet-in-the-middle kind of thing.
I have a different opinion. The Django docs are good, but not great. Here's how I see them right now:
- Combination of overview, how-to, and API reference.
- Overview section.
- How-To section.
- API reference.
The how-to section should show you how to do certain things. "Here's example code of how you can configure settings.py, how to handle an HTTPRequest in a view function, etc...".
The API reference, just a list of Django objects (showing inheritance), their attributes, functions, and parameters. Excellent example: http://api.rubyonrails.org/ . Currently some of this is documented, but some of it is only visible in source code.
Right now, everything in the Django docs is semi-bunched together. This made it really hard for me to initially learn the API; I'd imagine others' have similar issues. Since then I've gotten use to the docs, but it's still frustrating at times.
I do like Django very very much, but this is one of its pain points for me. It goes away with experience, but for new users it likely poses a bit of a challenge.
We're workin' on it, though, so if you'd like to help out I'd really appreciate it!
[] The length has nearly doubled in the last two years.
In the past I've submitted tickets via the Django ticketing system indicating errors/clarification/what-not for the docs, but almost every ticket got flagged as spam and didn't get submitted. I kinda gave up after that point. Any suggestions on how to get tickets submitted?
Oh, and one tiny feature request to the ticketing system: password reset. :)
Password reset is here: https://www.djangoproject.com/accounts/password/reset/
I'm not sure how customizable Trac is, but one idea would be to implement reCAPTCHA for anything marked as spam (assuming robots are causing spam issues and not users). If it gets solved, it's probably a human entering something on the other end.
This is a Python 2 reCAPTCHA module I forked/updated: https://github.com/dave-gallagher/recaptcha-client-1.0.6-ssl
The idea of 'Gems' in Rails(ruby) are exceptionally well engineered. Many powerful tools can be added by simply including a Gem.
On the Django side I have found the situation to be much worse. Many 'Apps' are hard to integrate and often it is easier to rewrite simple things than trying to customize them.
This is what caused me to switch to Rails after a year with Django
In the Convention over Configuration mindset, there doesn't seem to be a "best" convention for Django apps. You can install a django package easily through pip, but then does it need urls added, middleware, or signals added in your settings.py? The amount and quality of integration docs provided depends from package to package.
Rubygems combined with bundler is an excellent way to package up functionality, specifiy dependencies and have things play together nicely.
pip + virutalenv is similar, but not quite as good at this part - but python having module namespaces makes it far easier to write packages which you can be sure wont stomp all over each other.
In Rails/Ruby I can use Bundler:
git clone
bundle install
[do development]
git clone
_something_ install_my_dependencies
[do development]
foreach thing in file
pip install thing
It even supports SVN/SSH checkouts and .egg distributed packages.
[1] http://www.pip-installer.org/en/latest/requirement-format.ht...
I studied the requirement file documentation and I couldn't find a solution. It seems that to take advantage of this feature in pip I have to write a setup.py, and as I've mentioned that really doesn't make sense for my type of project. Or am I misunderstanding something?
pip freeze > requirements.txt
pip install -f requirements.txt
You are by no means required to make your source code a module or anything like that. If you use the above with a virtualenv you can isolate different models for different projects and have them frozen at different versions. You are also able to modify requirements.txt to include version specific information. packagename==3.4.0 now locks packagename to 3.4.0 when pip goes to install it.
I'm assuming your git directory looks like this:
$DIR
\
| - requirements.txt
| - fileone.py
| - filetwo.py
| - folder
\
| - __init__.py
| - filethree.py
pip install -r requirements.txt bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)
So what's happening here is the output of curl (a script) is being fed directly into a bash shell and executed. I think it's basically an awkward way of piping a command in reverse.
Why are there two "<" then? It seems to be required; when I try something like "bash < (curl -s ...)" it fails with syntax error.
http://tldp.org/LDP/abs/html/process-sub.html
Looks like the equivalent of the "read" example partway down the page. curl is actually being executed in a subshell.
The first "<" redirects the output of this file descriptor into the stdin of bash.
So both are needed, but you could just do it with a pipe :/
The way it works is that if you say
foo <(bar) -o >(baz) <(quuz)
foo /dev/fd/3 -o /dev/fd/4 /dev/fd/5
The way this works is that the shell opens pipes to the other command lines first, then generates filenames for them.
I did not know that you could use it with other I/O redirections such as <!
As a bonus, the <() syntax means you can pipe even to and from commands that don't read from stdin or stdout. They must not, however, depend on the ability to seek.
My most common use for this is nonlinear pipe flow, e.g.
diff -u <(sort -u file1) <(sort -u file2)
As a guy who happens to have a security background, I'd discourage admin interfaces built into the same app as the user app, especially when it's named /admin. Keep your admin functions in a separate and locked-down app if at all possible.
Take a look at the folder structure for the admin code in Django (contrib/admin). It has the same structure and conventions as any user app.
With Ruby, Rails oftentimes seems like the obvious framework, whereas the same can't be said for Python and Django.
Getting into Django has been a bit of a pain in the ass for me - at least for being unable to work on it organically with some fellow students or co-workers - but is there any reason to believe that getting a big Python framework community similar to Rails's is a plausible prospect?
Django for AppEngine is barely a variant, it's just a different handler for the ORM to interact with the non-relational backend. Jinja's a template engine that you can plug-in on top of Django if you want (like if you wanted to use HAML instead of ERB). Plenty of Django devs choose Tornado for their COMET needs (I know of almost no one that uses it as their entire web stack). Flask and Bottle are nice micro-frameworks, but aren't well-suited at all for large sites unless you feel like doing a lot of extra work yourself. Jekyll isn't a Python project, it's Ruby's static site generator (but does have a Python port called Hyde). Pylons (now Pyramid) is the only significant contender to Django. Think of it as Sinatra's market-share compared to Rails.
So when you actually compare the two, Python has no more "framework fragmentation" than Ruby. To someone outside of the community just listing off frameworks that they found on Google, sure it might seem that way.
From an outside perspective it looks like you are skimming the service and do not yet have a firm grasp as to the two communities and what they have provided. This is okay, it is something you can alleviate by simply learning more about the two communities, and hopefully in the future you will be able to provide your opinion on the state of frameworks based on correct information/facts.
So for folks who are trying to decide between Rails and Django, Or come from Java background, that is another framework to look at.
For an API: Sinatra. A CMS: Django. A sprawling web app: Rails.
Each frameworks was built to address a very specific set of problems.
Django was originally a CMS for a news site, so it's no surprise it's stayed good for that.
Django and Rails have long since outgrown their original, in-house roots.
On a side note, Django is far from being "minimalist"; http://flask.pocoo.org/ is minimalist, not django. I'll agree that Django is also less "Convention over Configuration" than Ruby.. for instance, it's a bit hard to chose where to put helper functinos in Django, whereas Rails put a helper file for you, etc.
http://download.oracle.com/javaee/6/tutorial/doc/gilik.html
Unfortunately JAX-RS has not been integrated with JSP or any templating languages yet.
Those interested in a C++ web app framework might consider wt (webtoolkit). It has a built in http/https web server and is thus plug&play for average applications. It is worth a look at.
I'll use an SQL db and CPython for the MVP, but I have an open road in front of me to optimize with NoSQL, PyPy, wherever it is required.
Note that there are many other parameters to consider, like ease of programming, toolbox richness, reliability of code, etc. The choice is up to you according to your weighting of theses parameters.
Check out Alex Gaynor's slides from DjangoCon for more info here: http://alexgaynor.net/2011/jun/07/djangocon-europe-2011-slid...
I did enjoy the article's touching on Django. It looks like it has gotten less monolithic than in prior versions. As I recall several years ago, Django really was like the Rails of Python, with tons of default options but some difficulties in customization. It looks like they have moved away from that somewhat.
Rails 3 is much easier to pull apart and put in pieces that you want. I believe this will be even easier with rails 3.1 introducing engines as a first class citizen.
Another way of saying it is I would like a framework that is "additive," where you start with a very lightweight core and then add components as you need them.
I'd say the two give you the same amount of framework code to start with. Rails just happens to let you see and fiddle with it right off the bat.
In any case, when I start a new project I don't want to worry about creating a bunch of files and remembering where to put them and doing all this setup. I just need some sane defaults, so that I can start making actual project-related decisions instead of fooling around with "how do I want to arrange my files this time?"