[Python-Dev] Suggestion: new 3 release with backwards compatibility (original) (raw)
Lennart Regebro regebro at gmail.com
Tue Jan 5 21:57:35 CET 2010
- Previous message: [Python-Dev] Suggestion: new 3 release with backwards compatibility
- Next message: [Python-Dev] Suggestion: new 3 release with backwards compatibility
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 5, 2010 at 21:24, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
It seems like this is a problem to be addressed, then. Let's get the "black magic" to be better specified and documented. <http://code.google.com/p/python-incompatibility/> is an interesting start on this, but it would be better if this work could be put into 2to3 fixers as well.
Some of it is about changing the code so 2to3 doesn't have to do ugly things. For example, always use iteritems(), so that 2to3 knows that items() can be used without converting it to a list, etc. Then we do have the problems with unicode vs string vs bytes, where I can't think of a clever solution except your no-op shims, which admittedly is fugly . For me that tends to turn into testing everything until the tests run on all platforms, which I guess is close to "black magic". Don't know what to do about that.
python-incompatibility is about documenting all differences, and also how to make code that runs under both 2.6 and 3.0 without 2to3. But I guess it should be extended into how to spell something that is clean in both 2.6 and 3.x.
The only workable workflow I've seen people propose for maintaining a single codebase with compatibility across both 2 and 3 is to use such tricks, with aliases to suppress some 2to3 updates when they are inappropriate, so that you can run 2to3 on install and have a single canonical Python 2 source.
Ian: If you have examples of 2to3 updated that are not appropriate (except the x.items() -> list(x.items()) they would be appreciated.
Seriously though, I find it hard to believe that this is a big problem. The 3.x source looks pretty similar to the 2.x source, and it's good to look at both if you're dealing with a 3.x issue.
In my experience it turned out to be less of a problem than I thought. That is to some extent because the modules I've ported has had good test coverage, and I have fixed 99.9% of the bugs by making the tests pass. Developing with Distributes 2to3 support has then been quite smooth and in most cases the separation between the 2.x source and the 3.x source hasn't been a problem.
-- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
- Previous message: [Python-Dev] Suggestion: new 3 release with backwards compatibility
- Next message: [Python-Dev] Suggestion: new 3 release with backwards compatibility
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]