• home
• about
• photos
• computing
• contact
• syndicate
• training

Comment

1. Jonathan, I’ve got to call you out on a couple things.
   
   You say:
   
   But its major problem is that everything is home grown, and if you end up running into limitations with the framework, there’s no “eject button” to allow you to switch out components easily.
   
   I say: using something else is as easy as importing it and using it just as you’d use any other Python code. Despite some vicious FUD on the O’Reilly Python blog to the contrary, Django doesn’t forbid you importing and using any Python code you like.
   
   If you mean that Pylons and TG somehow allow you to start a project with one set of components and then switch to another set *without rewriting any already-written code*, well, I’d like to see that trick ;)
   
   You say:
   
   But, the thing that truly irks me with Django is its lack of WSGI at the core. Sure, it has support for WSGI, but it feels bolted on, and isn’t a major aspect of its design or implementation as far as I can tell.
   
   I say: so, it’s bad to commit heavily to a component when the component is an ORM or templating engine, but good when the component is a web server gateway?
   
   You say:
   
   Now, Pylons, on the other hand, forces you to make a ton of decisions, right off the bat. This makes the barrier of entry very high, but prevents you from running into a situation where you can’t escape the decisions of the framework authors. Pylons also has WSGI at its very core, and will be able to take maximum advantage of reusable WSGI parts.
   
   I say: this is self-contradictory. What if the limitation I run into is one in WSGI? Don’t get me wrong, I like WSGI, but there are some hairy things in that spec that I’m happy to be able to escape from when needed.
   
   As I’ve written before, I think that ultimately the differences are simply personal taste; some folks like one way and some folks like another, and that’s fine by me. But generalizing from “I like doing it this way” to “this way is superior” isn’t fine by me, and even though I try to stay out of the framework-design debate these days, I’ll still call out anybody who tries that.
   — James Bennett    956 days ago    #
2. Good points James, and I don’t really think I disagree with you on any of them necessarily. Note that it isn’t my intention to bash on Django. Its simply an awesome framework, I am just outlining why I tend to use TurboGears over Django for many of my applications. Also, as you mention, this is all entirely a matter of opinion and personal taste, and NOT some sort of inherent superiority. Most of the reasons I outline in this post are, in fact, matters of personal taste and opinion.
   
   Your first point about being able to use other components in Django just by importing is well taken. Thats not my issue. The issue is that things like the admin interface won’t work if I just import SQLAlchemy instead of the Django ORM. This is a completely acceptable tradeoff for Django to make, and I have no issues with the approach. Its simply a different way of going about things, and a fine one at that. Because Django makes some opinionated decisions for you (ORM, templating, etc), it opens up the door for creating some really awesome things on top of those assumptions (admin UI, etc). Its a totally valid approach that I can appreciate. Its just that sometimes, you lose a lot of the great things about Django if you decide to go against the grain. Thats all I am getting at here.
   
   As for the WSGI point, I’ll stand behind this one. WSGI is the Python standard, and is definitely gaining traction every day. Django has done a good job of adding the support in after the fact, but like TurboGears 1.x, the support is bolted on and not really a core design decision. To be completely fair to Django, WSGI didn’t even exist when the project started, so I can’t fault them at all. I hope that in future versions of Django, putting WSGI at the core will be considered, as I think its an important standard.
   
   Your point about WSGI getting kinda hairy is definitely true, and I agree with you here. However, I think that the WSGI spec will evolve, and for a first version, WSGI opens up lots of opportunities for cross-framework integration, and general-purpose middleware.
   
   Finally, I’ll again agree with you that all of these things are a matter of opinion and personal taste, which is exactly why I said you can’t really go wrong in choosing any of the three major Python web frameworks, as they all have strengths and weaknesses that will play out depending on your application.
   
   Thanks for the feedback, you’re always one of the few opinions that I make sure to check for when reading up on something new and interesting that I see pop up on the Cheese Shop or Planet Python!
   — Jonathan LaCour    956 days ago    #
3. Jonathan, no worries. Aside from which tools we’re most comfortable with, I think we’ve always been largely in agreement.
   
   But as long as we’re being honest, my biggest concern as a Django user looking in on this aspect of TG/Pylons is that it feels as though not much thought has been given to the idea of reusable/”pluggable” applications.
   
   For example, if I have two TG apps, a blog application and a linkroll application, and they’ve made different component choices, I can keep them segregated in their own little walled gardens as distinct WSGI apps. But if I need to display content, or use functionality, from one on a page largely generated by the other, it feels like I’d be in for a bit of work to make them play nice with each other.
   
   Meanwhile, with Django it’s trivially easy to do just that, and the framework is designed to encourage that use case.
   
   So I guess I wonder if some of the difference in framework tastes doesn’t come down to a difference in which layer you want to make “plug and play”: for TG/Pylons it’s the component layer, whereas for Django it’s the application layer.
   — James Bennett    956 days ago    #
4. Also, Jonathan, you need to post more. If Adam and I have to pick on you to draw you out of the “dinosaurs” list in NetNewsWire, so be it ;)
   — James Bennett    956 days ago    #
5. Thanks for the comments James, and yes, I agree that I need to post more often :) Working for a startup certainly keeps you busy, and on top of that I’ve had some additional side-projects I have been working on that are taking up a lot of my remaining free time. Hopefully next year, I’ll have a bit more time for pulling myself up out of the Dinosaurs ;)
   
   Now, as for the concept of reusable/pluggable applications/components. The thing that is nice about WSGI, is that I can do things like the following:
   
   * Use the same session, cacheing, and authentication middleware across all my applications, regardless of the underlying framework (or lack of framework).
   * Deploy multiple WSGI applications in the same process, regardless of the underlying framework (or lack of framework).
   * Perform cross-cutting content filtering on all of these applications using middleware.
   * Coordinate my per-request transaction handling across frameworks using middleware.
   
   These are all really useful, and they really make the point about reusable low level components and deploying multiple applications in the same process. But, there is no discussion here of use cases like yours, where you want to be able to say, take a Django-driven linkroll micro-application, and place into your Pylons blog. I don’t really know that WSGI is the place to make that happen, but I think WSGI could be used as an example of how cross-framework integration is possible.
   
   I would love to see some sort of minimalist standard for mixing and matching these sorts of micro-applications. How great would that be? At some level, then choosing a framework would be entirely a matter of taste, and everyone would be able to benefit from the work of others.
   
   Imagine a world where I could create an application for project management out of off-the-shelf micro-applications:
   
   * A wiki application built in Pylons.
   * A knowledge base built in TurboGears.
   * A bug tracker built in Django.
   * A source code browser that is just a WSGI application.
   
   Wouldn’t it be cool if you could take these little parts and pieces and put them together into a cohesive skin? Some of the TurboGears 2.0 people are working on something called dbsprockets which I believe is actually an example of something very much like the above, although I have yet to play with it.
   — Jonathan LaCour    956 days ago    #
6. “Your first point about being able to use other components in Django just by importing is well taken. Thats not my issue. The issue is that things like the admin interface won’t work if I just import SQLAlchemy instead of the Django ORM.”
   
   Ok, I guess I will call you out on this straw man.
   
   The ‘admin app’ which comes with Django is a contrib application written on top of Django and is NOT Django its self. Don’t like it? Write your own. Anyone who points to one of the contrib apps as a reason not to use Django is spreading FUD. They are just some useful applications which come with Django. They are not part of the core framework its self. That is like saying your problem with python and the reason why you dont use it is because of ‘the crappy IDE IDLE’ (which others have done).
   
   NOTE: I would like to see you take a very complex introspective TG app written to SQLAlchemy and then replace the ORM with Storm and have it work out of the box. Not sure how one would even do that. I would not say TG is bad because of that. I would say that the app was tied to the ORM, and there for not of use to me.
   — Doug Napoleone    956 days ago    #
7. I don’t honestly know which layer is appropriate for it, but I do think that the “pluggable components” philosophy of TG/Pylons is going to present problems for truly “integratable” applications; it works well in Django precisely because Django users stick to the default stack. Making it work in TG/Pylons would require, at the very least, some sort of overarching abstraction to smooth out each app’s component choices, and I have a feeling that
   
   # It would end up being much more abstraction than anyone wants to realistically deal with, and
   # At that point the right name for it would be “J2EE” ;)
   
   This is, after all, what the Java world has been trying to do for years: hide the actual components behind layer upon layer of abstraction and indirection so that you can use the same generic API with anything (provided you supply the appropriate configuration).
   
   Again, it’s a matter of design decisions/taste: Django focuses on making pluggability/reusability easy at one layer, where TG/Pylons focus on making it easy at another layer. Which means that some things are easy in one framework and hard in another, but of such trade-offs careers are made ;)
   
   (though I’d be happen to be proven wrong, of course)
   — James Bennett    956 days ago    #
8. Relax Doug. Its not a straw man at all. I made the exact same point as you, and agree with you. I am certainly not spreading FUD, and am a fan of Django. Its a great framework. I understand the admin UI and how it fits into the Django world, and I stand behind what I said. Its nothing like the Python IDE comparison at all. The second item in the feature list of the Django website is “Automatic admin interface” and every single tutorial and screencast on Django makes it a huge part of the focus. There is a reason for that: its an awesome advantage for Django. Its something that deserves to be touted! But, it won’t work with SQLAlchemy or Storm. Nothing wrong with that, as I said before, as its a conscious design decision that is built upon the assumptions that you are using core django components (templating, orm, etc).
   
   I also never said that you could take a TG app and move the ORM from SQLAlchemy to Storm and have everything work out of the box. I wouldn’t make that argument, and its definitely not the point I am trying to make.
   
   Future Django commenters: I love you, and don’t want to fight. Lets have a beer and relax a bit ;)
   — Jonathan LaCour    956 days ago    #
9. Django’s approach results in something that is easy to use, with very few decisions for the programmer to have to make. But its major problem is that everything is home grown, and if you end up running into limitations with the framework, there’s no “eject button” to allow you to switch out components easily.
   
   I just don’t agree at all. The components in django are very loosely coupled. I “use django” but I don’t use the urls system, view system, or template system.
   
   I swapped all of them out, very easily, and built a resource driven architecture and mako templates. Now I’m left with a fantastic ORM and very nice request and response objects.
   — mikeal    956 days ago    #
10. You say:
    Over the next few years, I think we’re going to be seeing a huge push for WSGI in the Python world, with a ton of reusable parts that use WSGI as the glue.
    
    No, we’re not.
    
    Or to put it another way: why haven’t we already? WSGI’s been the Big Thing in the Python web world for what, over 3 years? And what do we have to show for it? Maybe 3 full-featured frameworks all doing the same thing and a boatload of incompatible abandonware
    
    Why are we in this sorry state of affairs? Because the WSGI standard is crap. No, really, go read it – but grab a six pack first because you’re going to want to hammer your brains out by the time you finish, if you get that far.
    
    Yes, having some standard is a good thing, but it’s a little astonishing that the best the Python community can come up with is one which makes Web programming harder. Maybe it’s better than nothing – I’m not so sure anymore. One thing I am sure of is that it’s kept low-level Python web development restricted to the in crowd that’s masochistic enough to implement the WSGI spec.
    
    Now if you’ll excuse me, I’ll finish reading this post.
    — Pete    956 days ago    #
11. I started with TurboGears then moved on to Django. It just wasn’t for me, as Django isn’t for you.
    
    Yay! We live in harmony!
    — superjared    956 days ago    #
12. >Future Django commenters: I love you, and don’t want to fight. Lets have a beer and relax a bit ;)
    
    I’ll take you up on that (if you’re offering to buy) ... will you be a PyCon?
    
    Seriously though – one more django commenter if you don’t mind:
    
    I’m sympathetic to your point of view. A year ago when I wanted to switch from PHP to Python for web dev work I initially liked the Best-of-Breed philosophy and choices of TurboGears better than what I read about Django (I also had some Kid exposure and like xml templates so that biased me a bit). I ended up switching to Django just because TG felt less stable to me – about to go 1.0 and lots of uncertainty about which components to use, where to go for Docs, etc.
    
    I still follow TG/Pylons and their constituent parts a bit and feel like good re-usable things (ToscaWidgets) will eventually emerge from it all. I’ve also discovered, however, that the complaints about being locked in to choices in Django are mostly overblown.
    
    What parts do you want to change?
    
    The url-to-view mapping? Ok, here you are stuck as far as I know. I don’t know why (other than importing existing code) you would want to switch – what can’t you do with regexes?
    
    How about Templates? You can use whatever template library you like and the only thing you lose is shortcuts (and I’ve whipped up my own 3 line replacements for render_to_response) and generic views (which I believe let you specify a template loader – you could probably hook into that to use alternate templates systems – I admit to not having actually tried this.) Mostly if you need a more feature-full or faster template lib you won’t be using generic views anyways I would think.
    
    The main thing I hear people wanting to switch out is the ORM system. I admit to lusting after SA on buzz factor alone and it would be nice to be able to use SA w/o losing the Admin (or at least without having to maintain two models – one for the admin and one for view manipulation in SA). I tend to prefer to outgrow the Django ORM and move to straight SQL, however, instead of trying to solve impedance mismatching/performance problems with yet more sophisticated ORMs.
    
    The point is, however, that yes Django is strongly opinionated. The general lack of magic makes it pretty easy to extend with other library choices, however, and I do see a case for having a site with a simple app using django orm, templates, generic views and admin and another more complex/performant app using other templating/ORM choices. I like having my hand held on the easy app and haven’t found it too complicated to swap out components for the more complex app in the same site…
    — simeon    956 days ago    #
13. Sorry, that was a bit harsher than I intended :-)
    — Doug Napoleone    956 days ago    #
14. Thanks for all the comments everyone! I can’t respond to every single one of the great opinions posted here, but a few stuck out to me:
    
    * James – You’re right about the dangers of creating a standard that ends up being J2EE! I still think there is a way to make interesting micro-apps embeddable in a cross framework way, without getting to that point. It might even be something I work on in the upcoming year, if I ever find time!
    
    * mikeal – I am aware that you can use Django without using any of the built-in options, you just lose a significant amount of benefit (in my personal opinion).
    
    * pete – I am not saying that WSGI is the greatest standard in the world, but it has already produced great progress in cross-framework integration. You can say “its crap” all you like, but it doesn’t reduce the usefulness of things like Beaker, Flup, WSGILog, WSGIRewrite, and all sorts of other nifty WSGI-based tools. WSGI 1.0 may not be the prettiest thing, but its certainly progress that I am willing to build upon.
    
    * simeon – I won’t be at PyCon this year, unfortunately, or I’d definitely be having beers with all of you! I will be in Las Vegas for a trade show with my business. And I totally agree with your feelings about Django feeling more stable than TG. Django’s approach lends itself to greater stability, better documentation, and a more “cohesive” feel.
    
    Whew. I should have known better than to blog on web frameworks ;)
    — Jonathan LaCour    955 days ago    #
15. “But, TurboGears 2.0 will be building on top of Pylons, and switching out all of the defaults to Paste, SQLAlchemy, and Genshi, with the option of running your application with any ORM, templating engine, and behind any WSGI server. To me, this is the best of both worlds.”
    
    A bit frustrating for anyone who bought the TurboGears book, DVD, soft toy and barbeque accessories, though, wouldn’t you say?
    
    If you take TurboGears as an entire project – 1.x and 2.0 together – what it has managed to reproduce is the Pylons experience, albeit with slightly better recent guidance on what components people should be using, and hopefully with better “icing” or “frosting” on top. But then, can we not justifiably anticipate the subsequent announcement of TurboGears 3.0 just as 2.0 passes through the gate, with a completely different set of recommended technologies as the architects realise that, for example, perhaps Genshi isn’t that great (just as the well-hyped and supposedly “best of breed” Kid templating suddenly fell out of favour)?
    
    Don’t misunderstand me here! The motivations behind TurboGears make sense: cut through the component proliferation that affects Pylons (and Web programming in general). A developer with little Web development experience isn’t going to be anything other than confused by the choice between a combination of AJAX libraries and templating libraries that Pylons appears to promote, let alone a choice of basic request/response abstractions – a situation that has been playing out for about four years while people act out their “market forces” fantasies.
    
    But people do want some value added, not only in terms of documentation and integration, but also in terms of longevity: the whole should be greater than the sum of the parts, not just now, but also over a long period, because the best architectural decisions should last the test of time. Project developers should be able to refine their impression of the “state of the art”, of course, but they should at least entertain the old ways of doing things that were happily promoted before. You can hype a technology and get people to buy the book, but maybe they won’t buy the next book if they feel that, in hindsight, the last one contains a load of material now disowned by the author. Perhaps, they might think, the author isn’t someone they should be listening to if he/she can’t settle on an established opinion despite writing a book on a subject.
    
    And perhaps that’s the difference one perceives when comparing Django and TurboGears: one group is rightly confident about what they’ve done (even if they don’t make all the choices I would); the other gives the impression that they’re having yet another go at getting it right (“but thanks for buying the book”).
    — Paul Boddie    955 days ago    #
16. Don’t take this the wrong way, but:
    
    Have you written any code that uses WSGI directly?
    
    I recognize that there’s a bunch of good, usable code built on top of WSGI. My point is that the universe of such libraries and *the ability of the vast majority of programmers to modify such code or write their own is severely limited* by the mind-numbing complexity of the WSGI spec.
    
    In short, I see WSGI as a cathedral to complexity and bad design
    — Pete    955 days ago    #
17. Paul, I think you bring up some good points about TurboGears. Trust me, I was very frustrated with how TurboGears took off and then hit a wall. Once that wall was hit, the “best of breed” components slowly lost their status as being the best, as better options came to the forefront. Major project contributors moved on to other things, and that left TurboGears in a bit of a sticky situation.
    
    I look at the move to build on top of Pylons as a highly pragmatic one. TurboGears instantly gains a significant chunk of really smart, motivated, and skilled core developers in guys like Ben Bangert, James Gardner, Philip Jenvey, and Mike Orr. Pylons has all the momentum that TurboGears lost, and a pretty compatible philosophy. As a TurboGears user, I was quite close to switching to Pylons entirely, and abandoning what appeared to be a sinking ship. But, using Pylons, there were some TurboGears features I was missing. Mark Ramm and I started talking about this, and decided to organize a sprint to see if we could bring some of those features to Pylons, and now here we are!
    
    Now, when it comes to moving from TurboGears 1.0 to TurboGears 2.0, there is a pretty good plan in place. TurboGears 1.1 will come out soon enough, and will flip the defaults from Kid to Genshi, and from SQLObject to SQLAlchemy. This gives people a good, stable transition path to begin moving to the new defaults in preparation for TurboGears 2.0. The move from Kid to Genshi is really not as big a deal as you are making it out to be. Genshi essentially is Kid 2.0, from a different author, since the original author decided to dedicate most of his time to Ruby on Rails development. The API is almost identical, with more speed, and a few new features. The move from SQLObject to SQLAlchemy is the biggie, and I won’t minimize that one. SQLObject and SQLAlchemy are very different, but Elixir brings them closer together, and might be a good option for people who are nervous about the transition.
    
    Once TurboGears 2.0 is out, the last real switch will be from CherryPy to WSGI/Paste. But, most of that will be shielded from the user, as they’ll still be using object dispatching, @expose, @validate, and all their favorite TurboGears 1.0 features.
    
    And, you’re right, Django has every right to be confident about what they’ve done. Since they have pretty much complete control over the full stack, its much less of a moving target, and is therefore easier to document. TurboGears is all about “best of breed” components, and is therefore going to change as new, better tools emerge. Does that mean your old code will stop working? No, but it means you have new, better options to work with when its time to do your next refactor.
    
    Again, I think all three of the aforementioned web frameworks are amazing, and all have their place, and a distinct style.
    — Jonathan LaCour    955 days ago    #
18. Pete – I have written a ton of software that uses WSGI directly. And I have no idea how anyone could misconstrue WSGI as being “mind-numbingly complex.” The entire spec essentially boils down to defining a callable that returns an iterable!
    
    As a person who uses WSGI literally every single day, I really have to say that the PEP authors did a fantastic job of creating something useful, and I think a simple search on the CheeseShop verifies that claim.
    — Jonathan LaCour    955 days ago    #
19. The only constant in TG is change…
    
    My perception is that the only stable thing is the TurboGears ‘brand’. Everything else is moving and changing. I really regret that I’ve choosen TG 0.9 for a non-trivial application long time ago. The Pylons/TG combination feels like yet another best-of-breed thing that might change not too far in the future.
    — Roman    955 days ago    #
20. The key point here is the plain lack of useful documentation. And this why Django is popular.
    
    Do you look at the source of Tomcat ? of the JDK ? No, you don’t as they have API and good doc_s_ and tutorial_s_.
    
    EOS.
    — Ludovic    954 days ago    #
21. One TurboGears poster after all those Django people :)
    
    I have to disagree with you on the statement that TG 1.0 has stagnated. TG supports Sqlachemy (0.4.x) and SQLObject out of the box in our latest betas.
    
    I must agree that the defaults of the quickstart have not changed, but this is on purpose. At the moment it is quite easy for anyone willing to quickstart a TurboGears project to use “tg-admin quickstart -s” to get a ready to roll SQLAlchemy compliant model.
    Contributors have also polished out Elixir templates.
    
    Assuredly the website does not reflect this and could be a little bit more lively, but I hope you don’t consider all our effort as just stagnating :-)
    
    1.1 will be the accomplishment of all this hard work and we hope to propose some further enhancements.
    
    I refer you to our changelog to see how things move in the 1.0 branch: TG Changelog
    
    Best regards,
    Florent.
    — Florent Aide    954 days ago    #
22. My response was so long, I had to blog about it.
    
    It’s the documentation stupid
    — Noah Gift    942 days ago    #
23. “””
    TurboGears 1.0 has somewhat stagnated, however, and you’re stuck with some pretty stale defaults with CherryPy, SQLObject, and Kid all having better alternatives available.
    “””
    
    Absolutely agreed. It’s all the old throwaways that nobody wants. No longer best of breed, it’s more like the Salvation Army/Goodwill of web frameworks.
    
    “””
    TurboGears 1.1 will be out soon, and will address the situation by providing better defaults for templating and ORM, but still leaving CherryPy at the center.
    “””
    
    When will it be out? More importantly, when will it be fully and properly documented? 1.0 still is not.
    
    “””
    But, TurboGears 2.0 will be building on top of Pylons, and switching out all of the defaults to Paste, SQLAlchemy, and Genshi, with the option of running your application with any ORM, templating engine, and behind any WSGI server.
    “””
    
    Sounds cool. When will it be out? When will it be fully and properly documented?
    
    Will there be yet another self-reinvention of TurboGears under way before 2.0 is released and documented?
    
    I was excited about TG in the fall of 2005. Color me skeptical in the winter of 2008.
    — Steve Bergman    941 days ago    #
24. Great points Steve. Documentation and direction are definitely areas that have plagued TurboGears for some time, and the decision to build on top of Pylons was made as a result of acknowledging those problems.
    
    A large portion of the original TurboGears leadership and documentation team fell entirely off the map just around the 1.0 release, leaving things in sort of a weird place. I think that a new group is rising up in its place, and providing a new direction. I know that Mark Ramm is going to do a great job in leading people, especially when it comes to the current state of the documenation, which seems to be a personal pet-peeve of his.
    
    So, I acknowledge and understand your skepticism. But, don’t write TurboGears off just yet!
    — Jonathan LaCour    940 days ago    #
25. Jonathan/Just so everyone is clear, my link “It is the Documentation stupid”, is supposed to be funny and if we were all in person it would be funny :)
    
    In my post, I wanted to point out that people that write documentation are very undervalued for, arguably, the most valuable part of a framework. It would be awesome if more people got paid to document open source projects.
    — Noah Gift    939 days ago    #

commenting closed for this article