On Tue, Dec 13, 2011 at 23:38, Nick Coghlan firstname.lastname@example.org wrote:
On Wed, Dec 14, 2011 at 8:17 AM, Michael Foord email@example.com wrote:
More specifically "six"  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.
Sure. This is different fixers, and then script to run it could have a parameter for version. I'd expect though that a 2to6 first targets 2.6+, and possibly never end up supporting 2.5 at all. I do realize there still is 2.4 out in the wild, but fewer and fewer people need to support it, and the effort to support it is much higher.
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.
Yeah, that can't be done automatically. There is no generic way to determine if a string should be binary, unicode or native.