|
Size: 1134
Comment:
|
Size: 1139
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 9: | Line 9: |
| *retain lib2to3 API since it is in use (perhaps depracate it later) | *retain lib2to3 API since it is in use (perhaps deprecate it later) |
| Line 14: | Line 14: |
| The discussions at the sprint pointed to a handful of essential coversions to | The discussions at the sprint pointed to a handful of essential conversions to |
| Line 18: | Line 18: |
| *convert strings to `u''` or `b''`, appropriately | *convert str or bytes to `u''` or `b''`, respectively |
3to2 is a project to convert cleaner 3.x code to 2.x.
3to2 started as a project idea to reuse the 2to3/lib2to3 codebase for converting 3.x code to 2.x. This creates a new package, 'refactor', which supports lib2to3 and (non-existent) lib3to2.
The following goals were targeted at the US PyCon 2009 sprint of Python Core:
- retain lib2to3 API since it is in use (perhaps deprecate it later)
- build a base package 'refactor' and port lib2to3 to it
- package refactor with a 3to2 script
- tackle high-priority conversions
The discussions at the sprint pointed to a handful of essential conversions to use as starting goals of 3to2:
from __future__ import * (2.6)
convert str or bytes to u'' or b'', respectively
convert print functions (2.5 and earlier)
- convert exceptions (2.5 and earlier)
How far back into 2.x should 3to2 go?
Conversions from 3.x to 2.4 and earlier have a lot more work to do than those of 3.x to 2.6 and later. :-) During the sprint, we approached tackling major conversion items (see short list above) for 3.x to 2.6, then 2.5, then 2.4, ...