On Oct 28, 2009, at 6:27 PM, Mario Ruggier wrote: > On Tue, Oct 27, 2009 at 9:27 PM, Mike Orr <[email protected]> > wrote: >> >> On Tue, Oct 27, 2009 at 4:07 AM, Mario Ruggier <[email protected]> >> wrote: >>> No-one seems to give any consideration to the very real >>> possibility of >>> adjusting the *same* code base to run on both py 2 *and* 3 -- the >>> same >>> tarball, the same setup.py. A recipe (and real world examples, one >>> of >>> which is a web fraemwork) for how this may be done is here: >>> http://mail.mems-exchange.org/durusmail/qp/441/ >> >> That would work in the short term, but it would suck to be limited to >> a subset of Python's features, and to have 'if's all over the place. > > There need only be one if block, centrally placed... all modules can > import specific items from there. > >> In the long term it would seem even more restraining, although >> presumably you could abandon the policy in a year or two. > > Well, yes, that's the price to pay for having a unique code base (and > dist package). In any case, you would still gain on other py3 > features, like performance, when running under py3. But, name me *one* > py3 feature for which a legacy package *must* have ?!? > >>> The mention of wsgi/py3/unicode issues in this thread reminded me of >>> an similar earlier exchange on this same group (some 10 months ago >>> in >>> Jan)... where in one of the replies Micheal Bayer had said '''There >>> are no "unicode" issues in WSGI''': >>> http://groups.google.com/group/pylons-discuss/browse_thread/thread/7840c48a1b14c5aa/9bb0444c8dd4611b?#9bb0444c8dd4611b >>> I guess it boils down to where does WSGI (should) end and where the >>> rest of the stack (should) start... plenty room for opinion! >> >> MikeB is not a framework developer. He's a database guy who has also >> written a remarkable template engine, > > Hey, so did I ;-)
And actually I do not say that lightly -- I still have to come across a templating task that can be done in Mako or any other python templating system and that cannot be done in Evoque -- on the contrary, in general it is done more simple and direct in Evoque. Even if you consider Evoque's "limitation" of handling only python expressions (i.e. no statements), in practice this is never a concern -- anything requiring a statement is in external pure-python (trusted) modules. The (big) gain... is that Evoque can be sandboxed (i.e. let your untrusted user modify the template source!), a feature that no other templating system had *designed-in* from the start. Anyhow, paying honour to Mako as the reference templating in python, here's a summary of differentiating features of Evoque: http://evoque.gizmojo.org/features/unique/ Plus, it is almost a year that it runs under python 3, as well as python 2.4+, from the same codebase. m. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
