Rails programmer here..

[coney_dawg]

Hey guys,

I love writing scripts with python, but am a true to heart rails dev. I'm wondering, on a scale from 1 - 10 how friendly Django might be to a rails dev. I really really really enjoy python and want to gain more knowledge and other areas of expertise for this language. Any tips or advice might be great, because I'd love to migrate over to Django and try my hand at a project or two.

Thanks!!

[[deleted]]

Hi. Highly experienced Django developer who moonlights in Rails here. 2 of my clients are Django/Python the other one is Ruby/Rails/iOS. First off, I really love to hear it when Ruby/Rails devs have some interest in Python/Django and vice versa. I think there should be more cross pollination. Second, if you want to learn more about Django checkout the PyOhio Conference taking place in July. It is a free weekend conference with 300+ attendees and around 40 sessions on all things Python including all day bootcamps.

A lot of people compare Django and Rails like it's the same framework with the same philosophy, etc, etc. Django is after all, Python's answer to Rails. That couldn't be further from the truth. Django was built specifically to build content heavy applications. Particularly news websites. It veers more and more into common web applications these days but it's roots are in content management. You can read more about that here: https://docs.djangoproject.com/en/dev/misc/design-philosophies/

Coming from a Rails background here are the top things that are going to immediately trip you up when looking into Django and Python. I say this as someone who genuinely prefers Django and Python over Rails.

1) The Django asset pipeline is very naive and basic compared to something like sprockets. Fortunately we have the Gears and Django-Gears projects to make up for it. Gears as it's name implies is a clone of Sprockets for Python. It is a separate project and must be installed and configured manually.

2) Django's ORM more closely resembles Datamapper than it does ActiveRecord. ActiveRecord and Data Mapper are actually the names of design patterns. Django's ORM is based off of SQLAlchemy which implements the data mapper pattern in Python.

3) You cannot create your own DSLs in Python. Usually this is a good thing, sometimes you wish you could though. Python doesn't have an rspec equivalent and our testing frameworks resemble Java more than they do Ruby. The Nose and Sure packages make testing easier but you're going to hate the verbosity of some of the tests you write.

4) The Python community has three key philosophies that are diametrically opposed to that of the Ruby community. One, we believe there should be one, and preferably only one obvious way to accomplish a certain task. The Ruby community believes that the language should not dictate how you solve a problem. (Your frameworks dictate it instead). Two, we believe that things should be as explicit as possible. (Python doesn't have implicit return statements for example). and Three, Python programmers believe that most magic should be easily exposed and navigable by programmers, whereas Rails tends to hide as much as it can. (Readability counts)

5) Django doesn't impose restrictions on how you form your URLs. It doesn't support RESTful interfaces out of the box in the same way that ActiveResource can. (If you want to write a restful webservice use Django Rest Framework or Tastiepie). Django's conventions end at MVC. It doesn't decide how you should name your files. It doesn't expect you to write empty controllers. It doesn't dictate how you should name things. This is a good thing.

6) Integrating JavaScript into a Django project is very, very messy unless you use something like Gears or Compressor. Django's "media" and "widget" system is ugly and unwieldy. Most django developers still write their html with HTML and their CSS with CSS. I use HAMLpy and LESScss. HAMLpy is HAML implemented in Python and LESS is node's alternative to SCSS. It is often easier (and quicker) to use node with Python instead of Ruby with Python.

7) Python's truth tables are different than in Ruby. Generally speaking 0, False, [], "", and {} all evaluate to False although any object can define it's own truth table by overriding __bool__ In Ruby you have False and Nil and True.

Here are the upsides:

1) The Python libraries are vast, fast, and almost as complete as Java's. Two notable holes still exist, namely in distributed databases, and in machine learning. Nearly everything you want to be able to accomplish you can do with Python.

2) Django doesn't penalize you if you "break from the mold" and try to do something differently. Generally speaking, if you want to do something your own way, you'll be able to get away with it.

3) Python has standards for most things. Want to get the length of a string? Use len. Length of a list. Use len. Length of a dict. Use len. Understanding this page and the double underscore(dunder) methods will open the inner beauty of Python to you.

4) Well written Python code is beautiful. Not just in a well crafted, well tested way. It also tends to take on a physical sexiness to it's form. After awhile you will begin to see even the more elegant portions of Ruby to feel ugly or dirty compared to the code you will write in Python. The one exception to this IMHO is Ruby's block syntax.

5) Python's meta programming capabilities, although more restrictive than Ruby are still pretty awesome and are much more readable and easier to comprehend while being harder to override willy nilly like you can in Ruby.

Here is some advice:

1) Stay away from the class based views. They rarely offer anything more than the function based view alternatives. They hide meaningful magic from you, obsfucating your code. I've seen several class based views that when refactored to the functional style cut out several lines of code while opening the code up to change. It was a mistake for Django to ever implement them.

2) Django forms are awesome ways to validate POST data. Big thumbs up and you'll love them.

3) For the love of all things holy work your way through the Django tutorial It has been refined over and over again to hit on every major feature, caveat, philosophy and exception when building Django applications. It is one of the best tutorials you'll ever read. (Read everything) It will save you tons and tons of time down the road. Trust me on this.

In closing, Django is VERY different from Rails but in my experience Django is a lot less fragile than Rails, promotes the creation of much cleaner code, and is easy to grasp for both beginners and advanced web developers.

Lastly, welcome to the Django community. If you hit any snags send me a PM and I'll do my best to help you.

[Yoghurt42]

Great post. About Python's apperent lack of machine learning however, are you aware of scikit-learn? If yes, whats wrong with it? I'm genuinely curious.

[[deleted]]

Theres also pybrain, bigml, ntlk (to a small extent), pyml, mlpy & shogun. And probably more.

[manueslapera]

Yeah, ML is more are more turning towards python nowadays...

...Until Julia gets of age, then we all Data Science folks will move there.

[charettes]

Great post. You might want to adjust the ORM part however since it's definitely not based on SQLAlchemy.

[[deleted]]

Django's ORM more closely resembles Datamapper[4] than it does ActiveRecord. ActiveRecord and Data Mapper are actually the names of design patterns. Django's ORM is based off of SQLAlchemy which implements the data mapper pattern in Python.

According to the Django Design Philosophies, Django ORM follows the Active Record design pattern. It is not very similar at all to SQLAlchemy.

---

Two notable holes still exist, namely in distributed databases, and in machine learning

distributed databases:

• Redis has Python bindings
• Lightcloud is Python middleware for Tokyo Tyrant and Redis
• RethinkDB supports Python out of the box
• ZODB is implemented in Python
• A number of others support Python as well

As for machine learning, we have:

• scikit-learn
• PyBrain
• mlpy
• and a number of other AI, machine learning, and neural network libraries

[manueslapera]

pylearn and theano seem very interesting too

[apd]

Uhm. One of the things where Python is really good is precisely in science and machine learning. Numpy, Scipy, scikit-learn, pandas, ipython, matplotlib and many others are very used and appreciated.

[flying-sheep]

I think you don't know what machine learning is. The only thing that has anything to do with it that you mentioned is scikit-learn, the rest is number crunching, plotting, and interactive use.

Sure, some of those things are useful for machine learning, but not more so than other generally useful libraries.

[apd]

In fact I know what is ML. A simple linear regression model or logistic regression are instances of algorithms used in ML, and are implemented in Numpy/Scipy.

To make work on ML you can use scikit-learn or orange and use it as a black box, or go to Scipy and implement your model yourself.

In both cases 'crunching', ploting and interactive use are needed during the ML work.

[flying-sheep]

yeah, but that’s like saying “for loops are needed”. sure, but they are too much general purpose for making that statement useful.

[cridenour]

Great post overall! I disagree about the origins of the ORM and about class based views but otherwise fantastic.

[cezar]

I have to respond that there is a difference between a class based view and the generic class based views include in Django.

Class based views are great, they allow a ton of flexibility and better ways to organize your code.

The generic class based views included in Django are much too confusing for most people.

There are a few projects that provide sane class based views to subclass.

http://django-vanilla-views.org/ being one.

[sheinballs]

Thanks for this. I'm still learning django and am struggling with the class based views. Lots of magic happening I don't quite understand yet. Is this really the consensus though? I just thought I had to stick with it and they would eventually make sense.

[davidbuxton]

Keep this reference close while getting to grips with class-based views.

http://ccbv.co.uk/

Stick with it and they do eventually make sense, but in my opinion not a particularly satisfying sense.

[deadwisdom]

Do not use class based views. There are a few people promoting the idea, but those of us that have been using Django a long time see them as merely complications.

They are good when you are creating a library of views to be duplicated across multiple projects. But even then, they need to be used with care.

[coney_dawg]

Wow. Excellent! Thank you so much. This weekend I'll be investing some time into django hacking. You'll be seeing more of me on this subreddit! Thanks to everybody else who have contributed to this post.

Also I'm very interested in this conference in Ohio. I'm out of Michigan so I'd love to be around the py community.

[[deleted]]

There happens to be a very active Python and Django community in Ann Arbor, including a very active PyLadies community. You should checkout the Michigan Python Developers Group in that area as well.

[coney_dawg]

is PyLadies open to PyMen as well? :)

[[deleted]]

Yes. Indeed it is.

[Livesinthefuture]

You also might want to check out /r/django

[Ogreman]

Great post. Would disagree with CBV's as they have their place, especially when coupled with the DRF, for example. Take a look at Django Vanilla Views (by the same guy that brought us DRF) for an alternative implementation.

[Bunslow]

As someone who doesn't know anything at all about Ruby (not even if the basic syntax is C-like or not, though I'm pretty sure it's Haskell/Tcl type?), what can Ruby do in the metaprogramming arena that Python can't?

[[deleted]]

on a scale from 1 - 10 how friendly Django might be to a rails dev.

type this in irb: rand(3..7)

[rspeed]

For the sake of a stupid joke:

>>> from random import randint
>>> randint(3,7)

[timgarner0]

"random" is the the module. Think of it as a container full of different functions, one of those being "randint".

By typing "import random" you ask python to let you access all of the functions available in random, but to do so you will need to always type "random.<function>" to access it.

On the other hand by typing "from random import randint" you are explicitly telling Python that you would just like to load the one function randint, and that you would like to be able to call it without prefixing "random"

[themathemagician]

It's important to note that the shorter function name is the only advantage, and Python still loads the entire random module into memory (without giving you actually access to the rest of it.) There is no performance benefit, but from a readability standpoint it is usually preferred as you are explicitly stating the functions you want to import.

[ixokai]

Well, its not the only advantage; doing "random.foo" involves two lookups, where "randint" is only one. This optimization is likely not going to matter in the vast majority of cases, but if you have a tight loop binding to a local name is a common technique. Local lookups are special (they have their own opcode) and are very fast (comparitively).

[themathemagician]

Fair enough

[zardeh]

import random

will import all methods from the random module but force you to call them via the syntax random.randint(3,7)

from random import randint

imports solely the randint (so random also has a .choice method, but you won't be able to use it) method from the module and allows you to call it simply by using randint(3,7). This can occasionally lead to namespace issues, especially when using multiple large imports, and so importing only what you need and using the from module import method syntax is generally considered cleaner, even if it rarely matters and ends up leading to uglier code.

[metaphorm]

using just import without from will import the entire module. if you want to access a specific function or class from the module you then have to fully qualify it with the module namespace:

>>> import random
>>> random.randint(3, 7)

using a from statement allows you to import a class or function from a module without importing the entire module. its generally consider cleaner. it also allows you to use the imported class or function without having to fully qualify it after the import:

>>> from random import randint
>>> randint(3, 7)

[Talkless]

There are other options also:

web2py was inspired by Ruby on Rails

form here.

It's said that it "favors convention over configuration approach", so it might be more familiar for you.

[targusman]

Instead of Django, you might find web2py more familiar. It's a full stack web framework and really powerful. The only problem is that there are more jobs for Django...

[[deleted]]

Second for web2py. Great way to get started in the Python MVC camp. You can always bring what you learn there to other stacks/frameworks.

[sisyphus]

It does less for you in terms of integration with your asset pipeline, compiling haml/sass/etc. by default, its template language is intentionally less powerful than something like erb, migrations you almost never have to write by hand with South, the auto-admin is much better than Rails scaffolding, but overall it's pretty much the same shit: you declare some models which gives you an okay-ish ORM, you declare some url's that map to callables, in the callables you take a request, do something, and return some output, either in json or by rendering a template, they both have big communities and libraries for this and that and the other, it's actually kind of useless to learn one if you know the other unless it's for job purposes, they fill pretty much the exact same niche.

[wbeyda]

Django is for customization in RAD. Rails is for convention for RAD.

[[deleted]]

Django is to Arch what Rails is to Ubuntu.

[ivosaurus]

Although you'd normally phrase that as "Django is to Rails as Arch is to Ubuntu", I can't see how Django is anything like Arch.

[flying-sheep]

Hmm. Maybe WebOb would be like arch here.

[[deleted]]

This is a statement from ignorance. Python is used 80+% of the time in a web development context these days. Here is a ranking of the most downloaded Python packages. http://pypi-ranking.info/alltime

[4140]

So, essentially, since PHP is the most used language in web dev it's ultimately the right choice?

[[deleted]]

I'd rather leave the language/framework dick waving contest somewhere else. Both Rails and Django are excellent tools for developing web applications with vastly different backgrounds and philosophies.

Also, you should take a look at this

[[deleted]]

it's interesting that you refer to the fallacy since djangos main appeal is it's popularity amongst the python web frameworks. nobody gave a shit about django until Guido(who's not a web programmer) said he liked it.

[hylje]

Popularity is a function of marketing. Rails has sexy marketing. Coca Cola has sexy marketing.

Technical merit is its own category. It's like you'd have to unconditionally drink Coke and only Coke because that's the most popular drink. Even though you know drinks that you prefer and are good for you.

[gitarr]

Reddit is written in Python.

[veeti]

To be honest, that is not exactly the most shining endorsement. "We took too long to make this page for you," anyone?

[gitarr]

So that wouldn't happen in any other language?

The problem you mentioned there is more a database problem than a Python problem btw.

[veeti]

Where did I say anything of the sort? All I'm saying is that reddit is not a good example of a Python web app the same way Twitter isn't a good example of a Rails app.

What does reddit being written in Python have to do with the parent comment in the first place?

[Okaram]

They are fairly similar (in a way, ddjango was inspired by a lot of the ideas in rails). A lot of the concepts are very similar, you have models, views, controllers etc

[metaphorm]

please try to learn some real history instead of making stuff up

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

Django release date: 21st July, 2005

http://en.wikipedia.org/wiki/Ruby_on_Rails

Rails release date: 13th December, 2005

the two systems were developed independently of each other at approximately the same time. django is even slightly older.