On Wed, Dec 14, 2011 at 8:17 AM, Michael Foord
More specifically "six" [1] is the name of Benjamin Peterson's support package to help write code that works on both 2 and 3. So the idea is that the conversion isn't just a straight syntax conversion - but that it [could] generate code using this library.
The thing is, the code you want to generate varies depending on whether you want to target 2.6+, or include 2.5 and earlier. For 2.6+, you can just use the print_function and unicode_literal __future__ imports to minimise overhead. But if 2.5 and earlier is in the mix, you need to lean more heavily on six (for u(), b() and print_()) String translation is also an open question. For some codebases, you want both u"" and "" to translate to a Unicode "" (either in Py3k or via the future import), but if a code base deals with WSGI-style native strings (by means of u"" for text, "" for native, b"" for binary), then the more appropriate translation is to use the future import and map them to "", str("") and b"" respectively. So, rather than an overall "2to6", it may be better to focus on *specific* fixers that can be tweaked or added to help with: 2.4+ -> 2.4+, 3.2+ 2.4+ -> 2.6+, 3.2+ 2.6+ -> 2.6+, 3.2+ 2.6+, 3.2+ -> 3.2+ (with handling of string literals being the most significant, and likely most complicated) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia