On Tue, Jan 5, 2010 at 21:24, Glyph Lefkowitz <gl...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to