On Jan 19, 2009, at 8:05 PM, Mike Orr wrote: > On Sun, Jan 18, 2009 at 4:05 PM, walterbyrd <walterb...@iname.com> > wrote: >> >> And if so, why? > > Everybody who uses Pylons knows that other frameworks exist and had > maybe tried one or two others, but has made a conscious choice that > they like Pylons' style better.
Hi Mike, I think I understand perfectly the intention of what you are saying here, but the last almost off-handish reference to "style" made me do a double-take on what you mean... What I do not "understand" is that given all the noisy promises of an ideal world where all python web applications are built following wsgi and installed with setuptools, the difference we are talking about cannot be simply written off as a matter of "style", but more architectural and philosophical. Pylons has, with the best of intentions, tried to embrace the "new" open-architecture as fully as possible. And, it pays and will continue to pay a fairly high price for that choice... Example of past price paid, just look at the number of what-should-be- a-non-issue installation problems in the mail archive. Example of price to pay, iiuc, apparently wsgi/paste/whatever has some unicode issues, so pylons has to wait for those to be fixed and third-party released to be able to even consider 3.0? Excuse me? I fully respect the choices that pylons makes, and almost always I am fine with them. There is anyway always a judgement call between wide- open genericity and narrower-scoped simplicity, and there is no "right" balance. Pylons probably errs towards the first, and django towards the second. But simplicity is very slippery, and very easily lost. The promise of generic inter-operational components more often than not exacts a higher price than what it gives back. How have the wsgi promises of inter-changeable web app building blocks measured up against the overhead from added complexities and issues? If you take for example qp, one of the few non-wsgi framework around, it strikes an amazing balance between simplicity and genericity, and it is not hindered by possibly-interfering impositions of a generic api such as wsgi. It can be used with or without the Durus object database that accompanies it, but it can (probably) just as easily also be used with sqlalchemy or any other ORM. QP also adopts the more robust single-thread multi- process approach to building apps, a choice that wsgi deems (pls correct and excuse me if I am saying something silly here!) to not particularly cater for. But, deployment of a qp app cannot be easier... SCGI works like a charm e.g. over apache, and is even more charming over lighttpd that has builtin support for it. Its "framework api" is grokkable in minutes... plus, a small additional fact, qp + durus (and the associated templating utility, qpy) have been available for python 3.0 since --day-1--, that is since the official first release date of python 3.0. All I am saying is that buying into a new way of doing things is fine but one has to be able to look back and sans-emotions admit what has actually worked and what has not. And, if at the beginning it the motivation was philosophical, playing it down in hindsight to a matter of style indicates to me that it has not all worked as well as hoped. > A lot of Django fans have done the > same of course, but a lot of other Django fans have not really looked > into any other frameworks, they just came to Django from Rails or PHP > because they heard about it first and didn't look any further. But this is a sociological fact, true of all software where the user- base goes beyond a certain "mass" -- blind following of the trend. But, I would add it is probably a good thing... everybody must go down his own path, and if django attracts people from rails/php, those same people will, after some experience with django forge their own opinions and preferences... and maybe some of them will then discover, and prefer, pylons. Or maybe they'll just go back to php ;-!! mario > -- > Mike Orr <sluggos...@gmail.com> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
