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. In the long term it would seem even more restraining, although presumably you could abandon the policy in a year or two. > This may certainly not be appropriate for some projects (and certainly > not recommendable to python newbees, absolutely go with 2.6!). > > 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, and a previous template engine that had some framework-y characteristics. The WSGI framework developers spent five hours in PyCon Open Space going over the Unicode and other issues I mentioned. WSGI is defined in terms of bytestrings, but they're called 'str' because that's what they are in Python 2. It would be a simple matter to say "Use the 'bytes' type in Python 3", and it would be a bit easier now that 'bytes' has acquired more string-like methods. But most applications/middlewares prefer to deal with Unicode. Except those that don't: the ones that don't care about character values. So either every middleware has to decode to Unicode and back to bytes, or the top level does it once. But then you get requests containing non-ASCII headers that don't have a character set specified. Purists would abort the transaction, but e-commerce sites don't want to lose out on a purchase simply because the user has a substandard user agent. So the debate has been, "To decode or not to decode?", with some default behavior for headers that can't be decoded. Some have suggested two sets of headers, one decoded and the other not. -- Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
