If people don't agree on the IF statement, they just don't agree on it. I find that I can discipline myself enough to use a full IF - having always used the py

If people don't agree on the IF statement, they just don't agree on it. I find that I can discipline myself enough to use a full IF - having always used the pyif (http://www.djangosnippets.org/snippets/130/ http://www.djangosnippets.org/snippets/130/) template tag in Django. I don't think this is such a big deal since one can swap out the templating layer in both Django and Rails for something they'd rather. If anyone reading this sees this as a big point, Liquid in Rails offers a more Django-like experience and Cheetah will give you things like full IFs in Python. You make a good point about not having to copy the code into the project directory and have multiple pieces of code sitting on the server. Someone pointed out that Rails Engines (included in 2.3) allow for this, but I haven't personally used them to know how nicely they work. For the security concern of auto-routes, this is actually a bigger concern in Python than in Ruby just because of the different ways that they handle OO stuff. In Python, everything is a public method. So, if Django just mapped URLs to methods, there would be no way of hiding a method you didn't want called. Ruby has the ability to make private and protected methods and Rails only makes public methods available as actions (the private and protected ones still being able to be called in their scope). So, it isn't a great security concern in Rails since it's trivial to define what is public and what isn't. Likewise, if one chooses, you can decide to map all of the URLs explicitly like Django and turn off the default :controller/:action/:id route. So, Rails offers both ways. Just as a note about Python: Django could just auto-map URLs to any method not starting with an underscore (the convention used in Python to say, this is kinda private even though Python will let you use it). Or there could be a kwarg (keyword argument) in the method signature that Django looked at. Anyway, there are ways around the fact that the Python language doesn't have explicitly private methods. Django's convention (like Python's) is just that explicit is better.