I've developed code on the web since the 90s from cgi to mod_perl to catalyst, openacs and dozens of frameworks inbetween. Roughly 16 months ago I was faced with a somewhat monumental task rewriting 90658 lines of PHP code based on Smarty with a basic framework.
After four months of working with Django and Turbogears, we selected Turbogears and dealt with the growing pains of the 2.0 beta through 2.0 release. Django 1.0 was released and we recently developed a small application for a client in Django. Compared to Turbogears, Django 1.0 was the right solution for that project. Django is better for writing a publishing site, Turbogears seems more well suited to a web application. Since TG2 is merely glue on top of Pylons and due to some outstanding issues and a community that is adversarial to those not in the core development group, we reevaluated the 14 months we spent on Turbogears to identify whether we were on the right track. For our application, there are a number of issues that forced particular choices in Turbogears. Workarounds for this, use this templating engine for that, add this code, patch this package, hold that dependency, file bugs, ask for help understanding the thought behind something and eventually have to dig into it and fix it. Sure, it's open source and I can fix it. We reevaluated where we were and what it would take to step back to Pylons and write our own glue (much the same as Turbogears had done). I knew Pylons could do the job, but, I wanted to write as little glue as I could to make the project work and then translate the 14 months of TurboGears development to Pylons. That required changing the templating engine and slightly modifying controllers to remove some of the Turbogears-isms. Required is probably the wrong word, enabled us to move to a better templating engine for our purposes would be more accurate. The documentation for almost every open source project leaves a lot to be desired. Pylons is no different. Certain examples are well documented, but some documentation is clearly written by a programmer and is almost a dump of the API with a comment thrown in. Even the authentication as mentioned in the pylons book and the wiki contains multiple comments showing some of that frustration. Documentation is no one's favorite task, but, good documentation helps adoption of a new platform. Django's documentation is extremely good and their snippet library contains numerous examples and chunks of code that can be borrowed. Sure, some of that code is pretty poorly written, but, it shows a vibrant community. Before you ask, yes, I do contribute documentation to projects. I've asked for help in the IRC channels on both Pylons and Django and have always gotten fairly quick, accurate responses. In one case, someone researched the answer, wrote an example, handed me a pastebin link with documented code and an example, along with my marked up code. I've seen the developers answer blogs around the net, reddit comments, twitter comments and that definitely points to an active, helpful community. Graham Dumpleton is inhuman in his coverage of mod_wsgi. Documentation of deployment in various situations and recommended deployment strategies is difficult to find for Pylons. A plain vanilla example is linked from the first page, but, not everyone wants to use Apache. There are people with certain hosting situations where Apache won't work as well for them. To get Pylons noticed, you almost have to follow the Release Often mantra. Look at some of the open source projects that publish every minor update to freshmeat, reddit, digg, etc every time there is a ; added. I wouldn't say to go overboard, but, I didn't even evaluate Pylons 14 months ago. Had I worked with it when I did the evaluation, I probably would have jumped ship from Turbogears quite a while back and not be faced with reworking as much code. The quickwiki example is a stroke of genius. If there was a documented example of an application that used quite a bit more of the framework showing its strengths, that would probably help. People coming to a project want an instant answer. They want to be able to install code, plug in 15 minutes of code and have instant results. Again, many of the wiki comments show that there is some frustration finding the answers. A comparison chart to other frameworks perhaps? A benefit statement? Frankly, the 'Why use Pylons' text is so generic and regurgitates the same text that almost every project uses to say why you should use them. Kudos for not being the 'premiere' python framework. The word premiere is too overused. * Combines the best ideas... What are the best ideas? * structured but flexible... How? * aims to make web development fast, flexible and easy... How? As for the comments on the web about frameworks, regrettably, if you have a hosting account, you can post 'facts' that other people believe. I've commented on blogs, pointed out errors in data collection methods for benchmarking and provided comments to people regarding website performance. There is so much misinformation published that anyone looking will find the first site listed in Google and accept that as an authoritative site. Comparing a poorly configured apache installation with nginx's more sane defaults and then publishing the results, posting to reddit/digg and getting a ton of pageviews and a top ranking in google = authority. >From what I've seen, Pylons stories barely hit the radar and Django stories are more frequent. Short of gst's reddit spam, pylons doesn't even get mentions and django easily has much more activity. Same with Digg... django versus pylons stories are probably a 4:1 slant. That public relations activity gets a project recognized. While I don't believe it should be a huge factor, the fact that Django runs on the app engine and Pylons doesn't is probably adding to Django's appeal among many. To me, Pylons isn't always going to be the right answer for a project. If I were writing a blog application, I would be much more inclined to write that using Django than Pylons. If I were writing a forum application, I would probably choose Pylons. While I prefer Pylons' paradigm, there is a slight 'overhead' to writing Pylons versus Django. On a larger scale project, that overhead isn't as large a portion of the time spent. If Django supported SQLAlchemy really well, or their ORM was much more powerful, I would be very hard pressed to choose Pylons over Django. You've got me, for better or worse, because of SQLAlchemy. All of the other components are similar enough between the Python frameworks that it is just a matter of syntax to switch from one to the other. How will Pylons differentiate itself from the rest? Answer that, and you'll be at the top of the heap. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
