From what you all say I think we do agree that it is not just a superficial question of style. It goes beyond that, and there is a price to pay -- and that the price is generally justifiable. And, as Micheal eloquently states, given the looming horizon, the line taken by pylons promises to attract more and more people in the future, as more people from other worlds will learn about what py3k really offers. But then again, the more eclipsed java developers come to pylons, the harder it will be for pylons to dearly hold on to that slippery simplicity... !
I of course agree with Jorge's argument on the advantages of a non- monolithic framework And yes of course that having different components to install will naturally give rise to numerous installation problems. But, it remains that that there were several strange setuptools-related problems when I first started to get pylons projects going, problems that I was not interested about in the very least. The bugginess on that front seems to be getting less, but without getting into endless religious discussions you have to admit there is an added sometimes-cryptic layer added about how packages are installed, where the py source code is, etc. And, "simplicity" suffers a little hit as a consequence. As for replacing components, I completely appreciate the possibility of doing so. If pylons did not allow me to use *the* state-of-the-art templating (that of course is http://evoque.gizmojo.org/ ;-) it would certainly be a less attractive framework. However most of the docs, default settings etc are geared towards a "default profile" of components, namely mako and SA. Go out of that mould, and you may have integration puzzles to solve, or in any case you are still dependent on the "unused" package anyway (in the case of mako). As for paste, I certainly do not want to fiddle with replacing the builtin dev web server -- has anyone (apart from pylons developers that is) even considered trying? Small anecdote about unicode issues, and migration to Py3k... unicode is unicode, be it py2 or py3. Nothing has changed conceptually in py3 on this, except that all strings are now unicode -- something that has been a best practice in py2 since how many years? As for "porting" evoque to py3k, once I got actually started on it, I ended up getting it done in one sitting. It was easy, mostly a superficial set of import and naming adjustments. Evoque also has a little library to automatically "guess" (with hints allowed) the encoding of a text file, so it certainly has to deal with encodings. But it was easy to do because the application internally was in the first place all unicode anyway. Cheers, mario On Jan 25, 2009, at 8:22 AM, Jorge Vargas wrote: > On Fri, Jan 23, 2009 at 7: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. > > search django list for geodjango, search for "using app X with app Y", > installations issues always happen when you have more than one source > of packages. That said most of the "installation issues" on this list > are simply people trying to get authkit going enough said. > >> 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? >> > now this is interesting. I actually see that as an advantage. if some > some reason paste becomes an evil thing, you simply drop it and > replace it for something better. It happen to SO with SA, it has > happen several times with templating engines. webob was introduced to > pylons and no one didn't even notice. If you look at the other side of > the track you just can't get rid of django ORM without killing half > the framework. > > So the price to pay is that you have to think what components you have > to use instead of simply following the needs of a newspaper editorial > room. Ok that sounded derogative :) Django is very good at some > things, pylons is good at all things and that comes with a price, but > a good price to pay. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
