what a strange post. There are no "unicode" issues in WSGI, and the usage of WSGI in the generic sense doesn't complicate things to any degree - the spec is just a single function call. If there are Py3K issues in Paste, lets first make it clear that *every* application that deals explicitly with character encodings needs code changes to work with Py3K. I can assure you any issues Paste has in this area will be resolved deftly and correctly by Ian Bicking.
The only price Pylons is paying is it assumes the developer would like to consider how his application should be architected, instead of those decisions being made implicitly and invisibly. This is a cultural situation created by the dominance of PHP, a decidedly "don't make me think / I didn't even know there was anything to think about" platform, in the LAMP world. If and when other cultures, such as that of the Java and .NET/C# communities (the theme of which would be, "we know how to code, let's do this exactly the way we think it should be"), decide to embrace Python more fully, projects like Pylons will establish a more prominent userbase. The most popular web frameworks in the Java community, such as Struts2 (nothing like Struts1) and Spring MVC, translate conceptually to a WSGI stack very directly. On Jan 23, 8:16 am, Mario Ruggier <ma...@ruggier.org> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
