Slashdot Mirror

← Back to Stories (view on slashdot.org)

Six Python Web Frameworks Compared

Posted by samzenpus on from the best-of-breed dept.

snydeq writes "InfoWorld's Rick Grehan provides an in-depth comparison of six Python Web frameworks, including CubicWeb, Django, Pyramid, Web.py, Web2py, and Zope 2. 'No matter what your needs or leanings as a Python developer might be, one of these frameworks promises to be a good fit,' Grehan writes. 'As usual, the choice is highly subjective. You will find zealots for each product, and every zealot is able to present rational reasons why their chosen framework is superior.'"

111 comments

  1. That One With The Fish Slapping Dance by Jeremiah+Cornelius · · Score: 2

    Really. Best of the lot. Much more direct than those oblique, "All-England Summarise Proust Competition" bits. Leave the PhD at home, and make 'em larf a bit!

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
    1. Re:That One With The Fish Slapping Dance by Boronx · · Score: 1

      More and bigger tits in the Proust competition.

      --
      Play Command HQ online
  2. Twisted by Anonymous Coward · · Score: 0

    Why isn't the Twisted web framework evaluated? It's one of the most popular for python.

    1. Re:Twisted by kiddygrinder · · Score: 1

      twisted isn't a web framework, it's an event driven networking engine

      --
      This is a joke. I am joking. Joke joke joke.
    2. Re:Twisted by hedleyroos · · Score: 1

      And interestingly twisted uses Zope's component architecture. It's pretty cool how the Python frameworks / apps try to play along with each other.

    3. Re:Twisted by GooberToo · · Score: 1

      I was disappointed TurboGears wasn't there.

  3. What?!? No Flasks or bottles in sight! by Terrasque · · Score: 3, Interesting

    Any python web framework shootout that features neither a flask nor a bottle is not worth drink...err reading!

    --
    It's The Golden Rule: "He who has the gold makes the rules."
    1. Re:What?!? No Flasks or bottles in sight! by Anonymous Coward · · Score: 0

      Agreed. Just another rather ad hoc selection, considering that neither flask or twisted is mentioned.
      From a worthy "comparison" one would expect a careful selection of frameworks then an analytic comparison.
      This article is just a pick list of features from the corresponding websites's boiler plates.

    2. Re:What?!? No Flasks or bottles in sight! by madprof · · Score: 1

      Agreed. As a Flask user, I reckon they missed a trick.

    3. Re:What?!? No Flasks or bottles in sight! by slippyblade · · Score: 1

      Mentioned before, Twisted IS NOT A WEB FRAMEWORK. It's a networking framework, completely different.

    4. Re:What?!? No Flasks or bottles in sight! by witch-doktor · · Score: 1

      Agreed. I use two small applications ( http://github.com/kghose/chotha, http://github.com/kghose/jabda) and I moved them from Ruby On Rails to bottlepy and have felt much better since. bottlepy is exactly the thing I needed for a basically desktop application that uses a browser as an interface.

  4. ironpython? by bhcompy · · Score: 1

    EVE is built on IronPython. I'd say that's pretty impressive and worth a comparison when talking about web targeted python

    1. Re:ironpython? by Anonymous Coward · · Score: 1

      Not quite. EVE's server is built on Stackless Python. IronPython is a .NET language that runs on the DLR. Neither of which are really relevant to the article. The article is about web frameworks that run on Python, not language derivatives.

    2. Re:ironpython? by itchythebear · · Score: 1

      I think you meant EVE is built with Stackless Python. Unless you where talking about a different EVE (I assumed EVE Online).

      --
      If what I just said sounded like a troll, it was probably just a failed attempt at humor.
    3. Re:ironpython? by bhcompy · · Score: 1

      Guess I'm wrong. Oops!

    4. Re:ironpython? by equex · · Score: 3, Funny

      Hey guys, someone admitted he was wrong about something on the internet. Print this thread and frame it on the wall!

      --
      Can I light a sig ?
    5. Re:ironpython? by Jonner · · Score: 1

      EVE is built on IronPython. I'd say that's pretty impressive and worth a comparison when talking about web targeted python

      IronPython is an implementation of the Python language, not a web framework. The six reviewed frameworks probably run on IronPython if one is so inclined.

    6. Re:ironpython? by Jonner · · Score: 1

      I think you meant EVE is built with Stackless Python. Unless you where talking about a different EVE (I assumed EVE Online).

      Stackless is another implementation of the language, upon which many web frameworks run.

    7. Re:ironpython? by citizenr · · Score: 1

      stackless sucks balls by not supporting more than one cpu core

      --
      Who logs in to gdm? Not I, said the duck.
    8. Re:ironpython? by PwnzerDragoon · · Score: 1

      ...As opposed to standard CPython? Yay GIL!

    9. Re:ironpython? by GooberToo · · Score: 1

      Depending on application design, python can support a surprisingly high level of concurrency. The main problem with the GIL is with multithreading but that doesn't mean python can't effectively leverage multiple CPUs. Furthermore, even with multithreading, if your application is heavily I/O bound, python frequently performs rather well. Its only in CPU bound multithreaded tasks and/or mixed loads whereby the GIL becomes a serious hindrance.

    10. Re:ironpython? by Anonymous Coward · · Score: 0

      EVE is built on Stackless.
      Second Life scripts use Mono (using a scripting language language that is not IronPython)

    11. Re:ironpython? by PwnzerDragoon · · Score: 1

      Nevertheless, due to the GIL only one thread can run at once. Yes, I/O bound tasks can benefit from threads, but this is more for architecture reasons than anything else; a thread not running due to the GIL is functionally the same as a thread not running because it's waiting for I/O. You can throw all the cores in the world at it, but they won't speed anything up and can actually slow it down. If you try to take full advantage of said cores for a CPU-bound task, which is what the GP was complaining about and where multi-core processors shine, neither CPython nor Stackless python will help with that (assuming all threads are in the same process). IronPython has this problem as well, but Jython lacks the GIL - it may be worth investigating if one was trying to do heavy-duty CPU-bound processing in Python.

    12. Re:ironpython? by GooberToo · · Score: 1

      Nevertheless, due to the GIL only one thread can run at once.

      Factually wrong. Period.

      I encourage you to learn more about python threading and the GIL limitations because you seem to know only half of the picture - the worst half.

      Only native python calls need block the GIL. This is why I/O almost never holds the GIL. Which means, I/O threads literally do run concurrently.

      Seriously, it sounds like you have no idea what the hell you're talking about and only know tidbits here and there. The fact you're providing a video of what I already addressed is downright sad.

    13. Re:ironpython? by PwnzerDragoon · · Score: 1

      Yes, you're right - native code called from a python script does not have GIL limitations. And Python code cannot directly interact with the hardware, so at some point all I/O code is native x86/x64/ARM/whatever binary code. I'm not denying I/O bound Python code can benefit from multithreading. The point I am trying to make, that was first brought up by citizenr way up there, is that for CPU-bound tasks both Stackless Python and CPython are effectively bound to a single core.

      I/O is irrelevant; I have never used Stackless Python so I can't say how it handles I/O bound operations, but if your code is bottlenecked by the CPU improving I/O performance won't make much of a difference. Native code is irrelevant, I am only talking about pure Python code here.

  5. Really? by FranTaylor · · Score: 1

    Oh really? The subject is "python web frameworks" and you assert that a ruby implementation will score well in this competition? I gotta ask, what version of python does "ruby on rails" support?

    1. Re:Really? by Mitchell314 · · Score: 2

      I'm pretty sure "import ruby.on.rails" should work in python.

      --
      I read TFA and all I got was this lousy cookie
    2. Re:Really? by rubycodez · · Score: 1

      Ruby does support a python, *in my pants*

  6. Doesn't matter which. At least it's not PHP! by Anonymous Coward · · Score: 0

    It doesn't matter which Python framework you choose. At least you're not using PHP!

    1. Re:Doesn't matter which. At least it's not PHP! by Anonymous Coward · · Score: 0

      Posting as anon, as I don't want to look stupid. I am trying to learn web development. Will learning a Python framework (I am looking at Django) be more beneficial for me from both career and usability perspectives than PHP?

    2. Re:Doesn't matter which. At least it's not PHP! by PeanutButterBreath · · Score: 1

      Usability, yes. Career, no.

      That's like asking whether getting an MBA in your 20s will be more beneficial from both career and competence perspectives than spending 10 years building actual businesses.

    3. Re:Doesn't matter which. At least it's not PHP! by SiggyTheViking · · Score: 1

      Not learning PHP will likely save you from hanging yourself with an Ethernet cable in shame once you discover how thoroughly PHP mutilates you mind.

    4. Re:Doesn't matter which. At least it's not PHP! by rubycodez · · Score: 2

      PHP isn't used much outside of web development. If you have web python skills you can also do other types of Python (command line, daemon) work. if you can get a job, the python one will generally be higher paying because it tends to be used for more technical, engineering, and scientific type applications. But, there are less web python than web php5 jobs.

    5. Re:Doesn't matter which. At least it's not PHP! by PCM2 · · Score: 5, Informative

      How much programming do you know now? Because if the answer is "very little" (or none), then you would do well to stay the hell away from PHP for as long as you can. PHP is useful because it's widely available on shared hosting servers, but as a language it is truly terrible. It will confuse you and leave you scratching your head at how to solve a problem at the same time that it's teaching you bad habits.

      Just for starters, PHP's library is full of inexplicable inconsistencies. For example, the arguments for mysql_query are "querystring, resource." The arguments for pg_query (for PostgreSQL) are "resource, querystring." Why? Don't ask. This is just one example of the typically slipshod way PHP has been put together. Note, also, that in both cases "resource" is optional. Die-hard PHP programmers will surely chime in at this point, telling you you're much better off using a database abstraction layer anyway, but which one? The PHP documentation lists four, but there are more than that.

      Python overall has been designed with much more care and forethought, is a much better language, and doesn't deserve to be put down like lame horses and PHP should be.

      That said, if you want to get more Web work, faster, learn PHP.

      --
      Breakfast served all day!
    6. Re:Doesn't matter which. At least it's not PHP! by Anonymous Coward · · Score: 1

      PHP is not very good for writing real web applications. It's a real PITA for doing anything sophisticated. The Python + Django combination will allow you to quickly create web apps of various complexities (you can use it to throw together a quick website or use it for large projects).

      I'd advise you to go with Python + Django but learn some PHP as well, just so you know what tools you have available to you. PHP has its place, as does Python and Django. Always try and use the best tool for the job :)

    7. Re:Doesn't matter which. At least it's not PHP! by Mordok-DestroyerOfWo · · Score: 1

      Not learning PHP will likely save you from hanging yourself with an Ethernet cable in shame once you discover how thoroughly PHP mutilates you mind.

      After writing my master's thesis in PHP I have to take umbrage at your characterization of me and my ilk. Now if you'll excuse me my cats are relaying messages from the aliens and get cranky if I'm not around to interpret.

      --
      "Never let your sense of morals prevent you from doing what is right" - Salvor Hardin
    8. Re:Doesn't matter which. At least it's not PHP! by Anonymous Coward · · Score: 0

      What the fuck kind of "educational institution" would allow a student to write a graduate-level thesis involving PHP?

    9. Re:Doesn't matter which. At least it's not PHP! by Tumbleweed · · Score: 4, Insightful

      Career-wise, there are WAY more PHP jobs than Python jobs, so if you're looking to be employed by someone else, PHP first (but don't stop with just one). If you're going to be doing your own projects, Python has evolved in a much more logical way than PHP.

      It depends on what kind of web development career you want - there are lots of specialties these days. Learn PHP, and learn all the associated web technologies REALLY WELL (html, css, javascript, ajax, etc). Get really good with an IDE (probably Eclipse). Learn how to use Photoshop and maybe Flash (or Edge). Learn SQL - MySQL especially, but also maybe some NoSQL tools. Learn the backend stuff like memcache, hadoop, etc.

      The more stuff you know, the more employable you will be.

      Learn how to write well. Being able to express yourself goes a long way in a technical career.

    10. Re:Doesn't matter which. At least it's not PHP! by Tumbleweed · · Score: 3, Informative

      Oh, and learn jQuery after you learn Javascript (not 'instead of').

    11. Re:Doesn't matter which. At least it's not PHP! by AliasMarlowe · · Score: 2

      Not learning PHP will likely save you from hanging yourself with an Ethernet cable in shame once you discover how thoroughly PHP mutilates you mind.

      Curse these flimsy UTP ethernet cables! They keep breaking when I put my full weight on them. Where is thickwire when you really need it?

      --
      Those who can make you believe absurdities can make you commit atrocities. - Voltaire
    12. Re:Doesn't matter which. At least it's not PHP! by Anonymous Coward · · Score: 0

      I work as a developer and Jython is used in HP's universal configuration management database or UCMDB. Jython is used in discovery scripts and jobs as well as federating various data sources into a single source. It tracks relationships and changes to see the impact on hardware/services/etc.

      Without my hobby of python, I'd not know as much as I do about jython which has been great for my career. Other less skilled VBish developers write horrid code and I'm the guy who debugs each issue and shows management how incompetent HP's foreign developer teams are.

      Learn Python. People don't always need low level developers and tend to focus on speed of development rather than speed of compiled code.

      Sad but true.

    13. Re:Doesn't matter which. At least it's not PHP! by mtinsley · · Score: 1

      Die-hard PHP programmers will surely chime in at this point, telling you you're much better off using a database abstraction layer anyway, but which one? The PHP documentation lists four

      I'm not understanding how that's a bad thing. PHP isn't the only language that has multiple extensions with overlapping functionality. The answer to "which one?" really depends on your needs (which is why there are multiple extensions in the first place). PDO is probably the most commonly used.

      Just for starters, PHP's library is full of inexplicable inconsistencies. For example, the arguments for mysql_query are "querystring, resource." The arguments for pg_query (for PostgreSQL) are "resource, querystring." Why?

      They are two completely separate extensions which you should never be using simultaneously. As you've already pointed out, if you can't, or don't want to, use a particular db extension, you should be using an abstraction layer.

      It will confuse you and leave you scratching your head at how to solve a problem ... That said, if you want to get more Web work, faster, learn PHP

      What?

      Because if the answer is "very little" (or none), then you would do well to stay the hell away from PHP for as long as you can

      I'm inclined to agree with this. PHP isn't a good idea if you're still learning the fundamentals.

    14. Re:Doesn't matter which. At least it's not PHP! by styrotech · · Score: 3, Interesting

      One thing to keep in mind with modern web development:

      Learning the server side language is only a small fraction of the total learning curve.

      You will need to eventually learn databases, a smattering of basic sysadmin skills, Javascript, HTML, CSS, a bit of HTTP, and not least the web frameworks or associated libraries and APIs themselves.

      With most frameworks sorta looking like MVC (whatever that ends up meaning these days) and the basic problems being the same, part of the learning curve of one system will help with learning another. Most web developers worth their salt will end up knowing multiple frameworks and server side languages anyway.

      You should actually try out both Django and something like Symphony2 (PHP) yourself to see which you prefer. Spend a week or so on each running through tutorials and creating demo sites. You'll soon get a feel for whatever you prefer.

      Career wise, language popularity isn't necessarily the most important thing really. Niches can still be profitable depending on where you are and supply/demand etc. eg there are plenty of PHP jobs, but standing out from the hordes of barely capable PHP developers can also be difficult for the less experienced.

      If you have to just start with one thing though, Django is a good choice. It's the most popular Python framework, and Python is a much better language for learning good coding habits than PHP. And if you later decide you prefer PHP (or the PHP job market), Symphony is still pretty similar from an architectural / functional point of view and having another language behind you gives a better idea of what not to do in PHP. Or if you end up really liking Python, you have lots of other options later for other frameworks if Django ends up being a bit limited or not quite to your taste.

      Just stay flexible and open minded, and know that web development will require ongoing learning no matter what.

    15. Re:Doesn't matter which. At least it's not PHP! by risom · · Score: 1

      Will learning a Python framework (I am looking at Django) be more beneficial for me from both career and usability perspectives than PHP?

      Depends ;)
      PHP's usability is clearly inferior (and looks worse, something that actually makes a difference if you look at code a few hours a day).
      PHP is used in more in simpler CMS engines (with obvious exceptions like Drupal), so if you are targetting smallish local shops looking for a relatively simple website, then I would advise learning PHP. Python on the other hand is mainly used in more complex environments (see the CMS/web programming framework Plone). A bit more work to get in, but it's also easier to make more money later. Plus it's more fun to program, and you learned a real language that's useful in other contexts.

    16. Re:Doesn't matter which. At least it's not PHP! by Fallingcow · · Score: 1

      I'd say pick any two of the Three Ps of web programming (Perl, Python, and PHP) and you'd be OK. Don't start with PHP.

      Perl and Python combined should give you enough job opportunities and make picking up PHP later a snap, while PHP plus either of the others should keep you from being a bad PHP coder.

      As a third one to try to get experience in, Java or asp.net are good choices. Both are annoying in their own ways, but IMO Java's nicer to work in. Don't forget Javascript, too--it's very different from most other languages you're likely to work in, and none of those other languages will give you much of a boost on learning it, the way, say, Perl would for PHP; it draws heavily from non-C-pattern languages, unlike all the others I mentioned, all of which are similar enough that if you know two or three of them the others can be picked up in a couple days (though HR won't see it that way).

      You'll be interfacing with databases constantly. Learn proper database design and the kinds of things SQL can do for you (more than you might think!) That's at least as important as any of the stuff above.

      Once you know a couple languages, the hard part will be learning new libraries and frameworks, not new languages (within reason--I recently had to try to make sense of some Erlang, and holy fuck...)

      If, after that stuff, you want more, try to get really good at configuring Apache and writing .htaccess files to accomplish various tasks. Maybe look at sort-of related tech you might have to work with, like the XML family (XSLT, Schema, etc.)

    17. Re:Doesn't matter which. At least it's not PHP! by PCM2 · · Score: 2

      The answer to "which one?" really depends on your needs (which is why there are multiple extensions in the first place).

      I disagree. The reason why there are so many extensions that do more or less the same thing is that nobody in the PHP community can agree on a good way to do something. And this goes double for the core language, which includes features that do the same thing already, except that the features in the core language are so bad that you should skip them and start looking for an extension to do it right. The end result is no two PHP programmers will be doing things the same way, because they each picked a different extension to solve the same problem that PHP failed to solve for them.

      What?

      You heard me. If you want to get a lot of work programming for the Web, don't learn Python, because Python is relatively uncommon in Web programming, while PHP is near ubiquitous. You will get more Web work knowing PHP than knowing Python. That doesn't change the fact that PHP is an awful, awful language.

      --
      Breakfast served all day!
    18. Re:Doesn't matter which. At least it's not PHP! by 1110110001 · · Score: 1

      In mysqli_query() the order is ressource, string. Don't use an outdated extension - problem solved.

  7. CubicWeb? by lejerdemayn · · Score: 1

    What the hell is that? Why was it chosen instead of flak/twisted/tornado/etc?

    1. Re:CubicWeb? by lejerdemayn · · Score: 1

      *flask

    2. Re:CubicWeb? by thatkid_2002 · · Score: 2

      The omission of Flask and CherryPy was indeed quite curious as they're certainly very popular.

      However I think that Twisted/Tornado are outside the scope of the article given that they aren't exactly web frameworks but rather components that can be used in web frameworks.

      I think the question that matters most of the time is not really "which framework" but rather "which database/ORM" or also "which templating system".

    3. Re:CubicWeb? by MtHuurne · · Score: 1

      It's made by Logilab, who also made pylint, a static code checker for Python. The logilab.org site runs on CubicWeb, so they are eating their own dog food.

  8. Flask? by andresambrois · · Score: 1

    I'm sorry to see he didn't consider Flask. I've found it to be a beautiful microframework suited for any task one might use Web.py for.
    If you are browsing for Python frameworks, you should give it a look.

  9. Zope 2, but not Zope 3? by PeanutButterBreath · · Score: 1

    Just asking.

    1. Re:Zope 2, but not Zope 3? by Ambassador+Kosh · · Score: 1

      Zope 3 is dead. It is a discontinued project. Zope 2 is the branch that is going forward. Bluebream is a sucessor to zope 3 but it is not an upgrade to zope 2. It was actually discussed that zope 2 should be renamed zope 4 to make that more clear but it was decided not to do that since it would confuse people.

      --
      Computer modeling for biotech drug manufacturing is HARD! :)
    2. Re:Zope 2, but not Zope 3? by PeanutButterBreath · · Score: 1

      Interesting. I'm glad I asked!

  10. Oh, python by ThorGod · · Score: 1, Interesting

    I dig python. I chose python + sqlite to clean data instead of excel and vba.

    1.) It's free (speech/beer)
    2.) It's multiplatform
    3.) It runs on my freebsd machine as easily as on my mac desktop
    4.) I can use a sqlite database exactly like a postgresql or mysql db in the python api (handy).
    5.) It added a line to my resume!
    etc etc

    I hope to never use python as a web designer (because I don't want to be a web dev - no offense). But, I definitely appreciate its generality.

    --
    PS: I don't reply to ACs.
    1. Re:Oh, python by Funnnny · · Score: 2

      I use bash to clean data: rm / -rf

    2. Re:Oh, python by Anonymous Coward · · Score: 0

      I use bash to clean data: rm / -rf

      I tried that but it told me: Permission denied. I think I need to use sudo to run this, yeah?

      What I don't grok though is how anyone would imagine that this is a pertinent reply to someone expressing a preference of python over vba?!

  11. In-depth? by halfnerd · · Score: 2

    Surely you are joking?

    1. Re:In-depth? by thatkid_2002 · · Score: 1

      Considering that most people these days have an attention span of 140 characters it was indeed in-depth.

    2. Re:In-depth? by styrotech · · Score: 1

      Yeah, I think calling that article a superficial once over would probably be overstating its depth.

    3. Re:In-depth? by Anonymous Coward · · Score: 0

      In the chart on page 3 of the overview article, if you click on the name of each framework, it leads to a more in-depth article on each framework (you have to register on the site to read the full version of each framework's article).

    4. Re:In-depth? by Anonymous Coward · · Score: 0

      Clearly this is meant to be the results of said in-depth review.

  12. Anything ready for the real world yet? by AtlantaSteve · · Score: 2

    The last time I tinkered with Django, I tried writing a simple CRUD app for an existing database at my job. After wasting a few hours learning how the ORM package works and setting up my models, I came to realize that Django does not support database tables with composite primary keys . In other words, it doesn't work with almost any legacy database that you will find in any enterprise shop on the planet. It wasn't worth re-working the schema, so I had to retreat back to Spring MVC and wrestle its XML.

    I'll give Django credit, though. It's still several steps ahead of Ruby on Rails, which my last experiment taught me doesn't support more than one database per app !

    I make a point to take one these "dynamic language" frameworks for a spin every 6-12 months... because I keep hearing that they are leapfrogging Java, and Oracle is destroying the universe anyway, and my career will be over soon if I don't migrate my skillset. So far I'm just not seeing it, though. These frameworks may be useful for simple non-commerce apps, stood up in a hurry by junior-level devs... but none of them seem remotely ready for any of the realities I deal with day-to-day when working for large companies or handling commerce.

    1. Re:Anything ready for the real world yet? by HipPriest · · Score: 1

      Try SQLAlchemy. It's simply awesome. The ORM by and for people who actually know relational databases. No "composite keys not supported". No "Legacy DB" FUD phrasing like Rails. Use it with Mako for templates and whatever web framework. Pylons/Pyramid works, as do others I'm sure, but to me the far more important choice is the ORM and templating system. The rest is just glue.

    2. Re:Anything ready for the real world yet? by Anonymous Coward · · Score: 0

      Keep checking back on this ticket. Composite keys have been a longstanding request in Django and it is being worked on.

      I work for a company and we use Django for a large, mission critical project. It's stood up very well so far, we've just had to make sure we know the limitations and design solutions accordingly :)

    3. Re:Anything ready for the real world yet? by Anonymous Coward · · Score: 0

      Frameworks are aids, not magic tools that do everything for you. They simply provide a starting point, and it's up to you the programmer to do the real coding and add all the interesting parts.

      An unskilled worker blames his tools, right. ...?

    4. Re:Anything ready for the real world yet? by Anonymous Coward · · Score: 0

      Multiple databases was introduced a while ago now

      https://docs.djangoproject.com/en/dev/topics/db/multi-db/

    5. Re:Anything ready for the real world yet? by AtlantaSteve · · Score: 1

      I know... that point was a reference to Rails.

    6. Re:Anything ready for the real world yet? by AtlantaSteve · · Score: 1

      I'm not sure why this guy got modded down... his answer was actually informative and useful. I'll check out SQLAlchemy next time I'm in a position to tinker.

    7. Re:Anything ready for the real world yet? by Jonner · · Score: 1

      The last time I tinkered with Django, I tried writing a simple CRUD app for an existing database at my job. After wasting a few hours learning how the ORM package works and setting up my models, I came to realize that Django does not support database tables with composite primary keys . In other words, it doesn't work with almost any legacy database that you will find in any enterprise shop on the planet. It wasn't worth re-working the schema, so I had to retreat back to Spring MVC and wrestle its XML.

      I'll give Django credit, though. It's still several steps ahead of Ruby on Rails, which my last experiment taught me doesn't support more than one database per app !

      I make a point to take one these "dynamic language" frameworks for a spin every 6-12 months... because I keep hearing that they are leapfrogging Java, and Oracle is destroying the universe anyway, and my career will be over soon if I don't migrate my skillset. So far I'm just not seeing it, though. These frameworks may be useful for simple non-commerce apps, stood up in a hurry by junior-level devs... but none of them seem remotely ready for any of the realities I deal with day-to-day when working for large companies or handling commerce.

      I haven't used any of the frameworks reviewed since where I work we have our own Python web framework. However, the thing that immediately struck me when reading the reviews is that several of the web frameworks have there own database abstraction libraries and/or ORMs, which seems wrong. Why should the DB access be tied to a web framework? I'd rather choose a framework that's good at the web stuff and a framework that's good at the DB stuff and not have one come with the other. I've been dabbling with SQLAlchemy which does support composite primary and foreign keys, unlike the ORM I have to use every day (much to my annoyance) and is not tied to any web framework.

    8. Re:Anything ready for the real world yet? by Anonymous Coward · · Score: 0

      Not sure why either. I used a mod point to up it, and someone apparently modded it down again already.

      Blatant "moderator disagreed" abuse.

    9. Re:Anything ready for the real world yet? by JohnnyBGod · · Score: 1

      After wasting a few hours learning how the ORM package works and setting up my models, I came to realize that Django does not support database tables with composite primary keys.

      It's somewhat convoluted, but you could make it work. You'd need to add an ID column, make that the primary key, add a unique-together constraint for those fields, and add a bit of custom SQL to create an index on those two fields (there's a way to put this in a file and make it run automatically).

    10. Re:Anything ready for the real world yet? by hedleyroos · · Score: 1

      I quite like Django's ORM. It's not as powerful as SqlAlchemy but it is easy to learn, and the Django guys put a lot of effort into documentation. I learned SQL the traditional way years ago and I'm still glad I did, but I don't particularly miss writing my own queries. If the ORM generates bad or slow SQL I can still drop to raw SQL.

      But I get your point re legacy systems. It sounds like a nice challenge to implement composite keys for Django.

      The big and powerful framework is Zope. Zope was also a driving force for the Python language over the years since the original Zope devs were also Python devs (and the creator of Python at one stage worked for Zope corp). Zope has contributed tons of libraries that can be re-used in other Python projects. They're very good community members.

      You are wrong about the frameworks not being as powerful as Oracle etc, but I don't blame you since it takes a long time to become familar with a large framework. I would also not have time to learn eg. any big Java framework, so I'm in the same boat.

    11. Re:Anything ready for the real world yet? by Caesar+Tjalbo · · Score: 1

      Why should the DB access be tied to a web framework?

      I belief it's part of what makes something like Django tick. All you do is create an object comparable to a non-web Python program and you work with it as such, the framework handles the rest. Or ask your question the other way round: why should you have to deal with the back-end when all you want to do is write a web-app.

      There's nothing wrong with your view and it's great if it works for you but it leads to what you describe: "we have our own Python web framework". I think you can imagine Django being useful for someone who doesn't want to concern himself with the db back end, even when that means accepting limitations on the db-side.

      --
      "I'm not much interested in interoperability. I want substitutability. I want to be able to throw your software out."
    12. Re:Anything ready for the real world yet? by Anonymous Coward · · Score: 0

      I came to realize that Django does not support database tables with composite primary keys . In other words, it doesn't work with almost any legacy database that you will find in any enterprise shop on the planet.

      Why "legacy" ?
      If I have to design a DB schema today, of course I tend to favor natural keys for most applications.
      Actually, a well known author of advanced SQL books and member of the standard committee used to call "ID-iots" the people that use surrogate keys everywhere.

      I did choose TurboGears over Django back in 2006 for that very reason (full SQLAlchemy and reflection support), and that homemade ERP is still operating quite well.
      It's a sad fact that most people use RDBMSs as glorified excel tables, and cannot unsee the row numbers.

    13. Re:Anything ready for the real world yet? by AtlantaSteve · · Score: 1

      Let me stop you at, "You'd need to add an ID column...".

      In a large enterprise shop, changing the schema for an established legacy database generally is not an option. There are usually dozens of live production applications tied into the existing schema, and management would never sign off on introducing needless risk for all of those.

      Even if you did get approval to move forward, you would need to time and QA resources to fully regression test all of those apps (assuming you identified them all and didn't miss any odd stragglers). Many of those apps would inevitably need modification, because they were coded by offshore or junior-level devs with sloppy practices (e.g. raw SQL that uses column position numbers rather than column names).

      For even a mid-size company, "adding an ID column" might take several months and a few hundred thousand dollars. You don't do that. You might try a workaround of creating custom database views just for the new app, mimicking the schema that your framework needs. Better yet, you just search for a more powerful ORM framework (perhaps this SQLAlchemy package?). Most likely of all, you simply use Java in the first place... because its leading frameworks are built by people who are used to working in these environments and dealing with such considerations.

    14. Re:Anything ready for the real world yet? by AtlantaSteve · · Score: 1

      You are wrong about the frameworks not being as powerful as Oracle etc, but I don't blame you since it takes a long time to become familar with a large framework. I would also not have time to learn eg. any big Java framework, so I'm in the same boat.

      I'm not trying to be a jerk, but I'm not sure you have a basis for comparison. "Oracle" is not a Java framework, it's just the company that acquired the Java trademarks from Sun. I guess they own the trademark for JEE too... but that's not really a "framework", and its direction isn't so much identified with Oracle. Java web frameworks would include things like Spring (used by most shops these days), Seam, Struts, Wicket, etc.

      Anyway, I have written apps in "dynamic language" frameworks... including Rails, Django (sorta), Symfony, CakePHP, and node.js. It's just not the same. It's like comparing a car to a space shuttle.

      That said, I don't mean that these frameworks are inherently "inferior" to Java frameworks. I'm just saying that they are different tools for different jobs. If you're building a site that isn't heavily dynamic on in the back-end yet needs to integrate easily with front-end AJAX, and you don't want to recruit and pay more for developers with experience in commerce or large enterprise systems... then it might be silly to insist on a full Spring stack. At the same time, if you're a large institution, writing an app through which business will be conducted or money changing hands... then you probably don't want a dynamic language framework, because the framework and its developer talent pool are not as accustomed to dealing with the challenges that your project will face.

      When we're used to swinging a hammer, everything starts to look like a nail... but the reality is that there is plenty of room for both a hammer and a screwdriver in the toolbox.

    15. Re:Anything ready for the real world yet? by GooberToo · · Score: 1

      Welcome to slashdot. Its the original home of, "the retarded kid has a stick and he's not afraid to use it."

    16. Re:Anything ready for the real world yet? by hedleyroos · · Score: 1
      I agree mostly with what you said. And of course I know Oracle is the company and not the framework :)

      When we're used to swinging a hammer, everything starts to look like a nail... but the reality is that there is plenty of room for both a hammer and a screwdriver in the toolbox.

      My hammer would be called Plone. It runs on top of Zope. I love it but it is not a good fit for small systems.

    17. Re:Anything ready for the real world yet? by Kazin · · Score: 1

      Yes, but when you have to deal with an *existing database* that has composite keys, you're out of luck.

    18. Re:Anything ready for the real world yet? by Anonymous Coward · · Score: 0

      It's still several steps ahead of Ruby on Rails, which my last experiment taught me doesn't support more than one database per app !

      Ha you didn't experiment in much depth then did you. Hint try ActiveRecord::Base.establish_connection for multiple db connections per application.

      Probably, distracted by all that "really-important-commercial-senior-level-enterprise" work you were doing for "large companies". :P

    19. Re:Anything ready for the real world yet? by Anonymous Coward · · Score: 0

      "Django does not support database tables with composite primary keys"

      There is a current GSOC project to add that feature

    20. Re:Anything ready for the real world yet? by Terrasque · · Score: 1

      Hey, just wanted to chime in a bit here. As many others have mentioned, SQLAlchemy supports just about everything pretty well, but IMHO it got the disadvantage of being way too complex for 90% of what you want to do (and also have confusing docs).

      Django's ORM is much smaller, more compact, sacrifices some advanced features, and is (again, IMHO) much easier to work with, and got solid docs.

      But, here's the thing. You can use SQLAlchemy in Django. You can even use both Django ORM and SQLAlchemy in the same project. One example, one work project here, does order registration and processing, and all that is done via Django's ORM. In addition, it needs to talk to our billing system, which is run on a MSSQL monstrosity of a DB. I use SQLAlchemy for that.

      Got a 1500 line module that does all the details there (handling manual primary key increments *yikes*, weird date format *yikes yikes*, translating 2-char field names to logical names *yikes^3*, relations, composite primary keys, and so on), so my normal django code can just use and work with data from that external DB more or less normally. Works perfect, and peaches and bunnies lives happily ever after.

      And as a result, I get the best of both worlds :D

      --
      It's The Golden Rule: "He who has the gold makes the rules."
  13. My absolute best Python feature by Anonymous Coward · · Score: 0

    Python code is very easy to read. You can code something in fewer lines. The result is fewer bugs and easier troubleshooting.

    Ease of reading Python code makes it easy to pick up someone else's code or even your own code after a year or so.

    If Python will do the job, it's my automatic choice. For code that I write for my own use, that means almost anything that isn't embedded or a device driver.

    1. Re:My absolute best Python feature by g4b · · Score: 1

      agreed. i usually started to write pseudocode in python. which is handy. since you can run your pseudocode.

  14. SQLAlchemy by slackergod · · Score: 2

    While I'd like to it not be the case, I'd have to agree with you about the general not-quite-there-yet state of dynamic frameworks. That said, Django's custom ORM leaves much to be desired. Next time you decide to give a python framework a try, pick one which uses SQLAlchemy as it's ORM layer. You'll find it to be a much more sophisticated library (similar to Java's Hibernate). In particular, it has all the features you just mentioned. Not integrating SQLAlchemy is one of the main things that keeps me from using Django... any other ORM layer in Python seems doomed to play catch-up.

    1. Re:SQLAlchemy by Anonymous Coward · · Score: 0

      You're not actually stuck with Django's ORM. You can use SQLAlchemy. You can even replace Django's templating system (Jinja2 is popular).

    2. Re:SQLAlchemy by Anonymous Coward · · Score: 0

      You can use sqlalchemy, sure, in the sense that "use" means "not using any of the model layer integration whatsoever". As in, you can use it like you weren't using a framework at all.

      Django is pretty slick for what it does, but when you run into its limits, you're totally out of luck.

  15. Easy guide? by Anonymous Coward · · Score: 0

    I've coded a few small apps in Python, mostly for scientific/engineering applications (nothing big). Not being a CS major, I've never felt comfortable with GUI apps with Python or Django. Is there any "dummies guide" that guides you step-by-step in creating a webpage? I'd love to create a page where I can store engineering data on a server, and have a Python coded page pull that data and display it in graphs with user preferences (for example, say plotting thermal conductivity of a material vs. strength from a drop menu). Out of my league here?

    1. Re:Easy guide? by An+ominous+Cow+art · · Score: 1

      These projects sometimes (usually?) have some sort of tutorial showing how to set up a simple website. I know Django and TurboGears do; I'm not sure about the others.

  16. Web.py is great by Fnkmaster · · Score: 1

    Web.py is great for developing web services. Really, really quick and easy to learn. The documentation is probably about a 7 though, I agree with that. However, I'd give it 9s on everything else.

    Web.py+mimerender is pretty sweet. Check out the example code here:

    http://stackoverflow.com/questions/713847/recommendations-of-python-rest-web-services-framework

    I find this infinitely more comprehensible, pythonic, and nice to work with than the other Python web frameworks I've seen. I've never really used Django, but the examples I've seen look pukey to me.

  17. How does Turbogears compare these days? by presidenteloco · · Score: 1

    It was probably the best all-in-one python webapp-building mega-framework 5 years ago.

    I found Turbogears great because it eliminated (unnecessary) choices (i.e. all mandatory convention),
    and pretty much just worked out of the box (modify a working trivial webapp was the way you got started.)

    How does its latest version compare to these others? Anyone have an opinion on that?

    If TG is no longer competitve, why, and which other one has its good features like I described above?

    --

    Where are we going and why are we in a handbasket?
    1. Re:How does Turbogears compare these days? by LesFerg · · Score: 1

      Not sure where it is at now, I bought the book when it was *current* and really liked the framework, but didn't get into developing a live app with it at the time.
      When I recently went back to look at using it, they have replaced 2 or 3 or more of the base libraries and the book appears to be redundant. Haven't yet investigated enough to see if there are clear and useful instructions available online for getting up and running with the latest version, but I would like to see an in-depth guide to things that are different from the book that was originally published.

      --
      If I had a DeLorean... I would probably only drive it from time to time.
    2. Re:How does Turbogears compare these days? by greg1104 · · Score: 1

      TurboGears never managed to get enough momentum in terms of code contributors to really prosper. You can get a feel for some of the saga just by reading the project's Wikipedia page. It lives or dies based on the contributions of a few key people, and that group had the misfortune of stalling right as Django in particular was really picking up a lot of steam around two years ago.

    3. Re:How does Turbogears compare these days? by presidenteloco · · Score: 1

      "had the misfortune of stalling right as Django in particular was really picking up a lot of steam"

      which is really too bad because Django is freakin' weird. (e.g. it calls a controller a view, seemingly just for fun.)

      --

      Where are we going and why are we in a handbasket?
  18. missing tornado.... by anon+mouse-cow-aard · · Score: 1

    http://www.tornadoweb.org/ -- This one looks interesting to me. I would like to try this one. Anyone used it?

    1. Re:missing tornado.... by codepunk · · Score: 1

      Yes it is the only one I like, very close to app engine and extremely fast.

      --


      Got Code?
    2. Re:missing tornado.... by Riskable · · Score: 1

      I have written a few apps using Tornado... So far it is my favorite framework for developing rich web applications. I contributed code/patches that the Tornado devs used to add SSL support to the framework. Also, just the other day I completed a Kerberos/AD/SSO authentication module for Tornado (I'll be making it available soon I hope).

      My favorite feature of Tornado is the built-in support for WebSockets. It should also be mentioned that it is one of (if not THE) fastest Python web frameworks.

      I also want to mention that for one-off/quick development web applications that don't need to be super fast I almost always use CherryPy. It is much simpler/quicker to develop with CherryPy than Tornado. You lose out big time on speed but the development time of CherryPy apps is very impressive. I wrote a reporting tool for my job that would examine a passwd file and then check it against Active Directory for uid/gid/shell/homedir conflicts and report the results on a pretty page using jqGrid. Users could even click a button to export the grid to spreadsheet format. Total development time: 16 hours (and that includes lunch breaks and five or six hour long conference calls)! Needless to say my boss was ecstatic, my coworkers were amazed, and the people who ended up using the tool asked me how much it cost (as if we bought it).

      To bridge the gap between CherryPy and Tornado I actually wrote a MethodDispatcher that lets you port a CherryPy app to Tornado with a trivial amount of effort. Of course, it also lets you write a Tornado app "the CherryPy way" which, while a bit strange sitting on top of Tornado, is much simpler and allows for faster development time.

      As for the differences between some popular frameworks I wrote up a pretty good explanation over at Stackoverflow.

      For reference, here's some apps I've developed using Tornado: Gate One (still developing it), PyCI (no longer maintaining it though--I hope to revisit it some day when I have time, sigh), Escape From The Web, and here's a writeup of mine on how to develop an application similar to my reporting tool using CherryPy and jqGrid in no time at all.

      --
      -Riskable
      "Those who choose proprietary software will pay for their decision!"
  19. Performance and resource usage? by forevermore · · Score: 1

    Maybe CPUs are so cheap these days that it doesn't matter, but I really like to see speed/performance as a metric when evaluating the technology that runs my website.

    --
    Do you really need reason for beer? Wingman Brewers
    1. Re:Performance and resource usage? by greg1104 · · Score: 1

      Any sort of useful benchmarking here would take an article a hundred times more difficult to write than the work that went into this one. Performance for this class of applications is so dependent on workload that the idea of evaluating their speed can't happen usefully without a large amount of testing. There are possibilities for almost every layer that multiply together for the number of configurations to consider. For each framework, you'd need to evaluate each of the web server possibilities, each of the database backends, tune all of them and the framework usefully, pick a couple of different use cases (varying the read vs. write ratio in particular), try a number of concurrency levels, and then track both page throughput and latency. By the time you finished, new versions would be out and you'd have to throw out the results and start over.

  20. Heard of 2 of them by Anonymous Coward · · Score: 0

    Heard of Django and looked inside Zope, never heard of the others.

    Oh, and don't care (same goes for these ridiculous Ruby based things).

    PHP won the war. (And I'm speaking as a heavy duty Python devel btw).

  21. Tornado by codepunk · · Score: 1

    The only python one I have tried and liked so far is tornado.

    --


    Got Code?
  22. interesting comparison of python to php by Anonymous Coward · · Score: 0

    yeah the article is missing bottle, flask, and it's pretty thin on content. probably better to reference php versus the r-langauge.

  23. Loving web2py by Anonymous Coward · · Score: 0

    I haven't looked seriously at any other Python web frameworks besides Django, but I've found web2py to be a wonderful environment to work with. Coming from Rails, web2py's philosophy of ensuring new releases maintain backwards compatibility is an ENORMOUS plus - I got sick of tracking down new problems in my existing codebase with each new major Rails release. I understand why Rails does this, but in practice it's incredibly annoying having to make wholesale changes to your previously-working code every so often

    web2py's community is also first rate - I know the same applies to Django and to Python in general, but again it's a breath of fresh air compared to some others.

  24. time for a good eve' python summary. by g4b · · Score: 1

    yeah, lets summarize all of it. for fun.

    0. eve runs on stackless python. (server and client. using dx9, not ogl (those bastards!))
    1. stackless is cpython without a stack, hence the name. (one core limitation is not stackless' fault)
    2. ironpython is python on .net (web frameworks might also run there, who really knows? or cares?)
    3. jython is python on java (at least django runs on that one)
    4. these are interpreters. if you dont like it, i have others. also, i have to dock my mackinaw now. ice, ice, baby.
    5. ???
    6. CALDARI!!!!!!

    had to post on eve thread. my clone wanted me to do it.

  25. Pointless by Anonymous Coward · · Score: 0

    On a scale of 7 to 9, and we only get 0.7 difference between worst to best. Essentially: "I cannot tell if they are different, it all looks the same to me."

    What a piece of crap.

  26. web2py rules! by Anonymous Coward · · Score: 0

    Great article. If anything I am surprised how close some of the others scored compared to web2py. In terms of power, usability, and documentation web2py is the new standard.

  27. "Six Python Web Frameworks Compared"? Holy crap. by Petersko · · Score: 1

    Must be nice to have nothing better to dlo.

  28. bobo by Anonymous Coward · · Score: 0

    What about bobo?

    http://bobo.digicool.com/