leo\extensions\docutils is intended to work (eventually) on either Python 2.x or 3.x. I spent much of yesterday investigating what is required.
The 2to3 tool might be used to create such a common code base automatically, or semi-automatically. I wrote Guido and David Goodger about this idea, but they are busy with other projects. The following is my letter to them. I'd like your comments. QQQQQ **Executive summary**: 2to3 isn't so useful for creating a common code base that will run unchanged on both Python 2 and 3. Relatively minor changes to 2to3 would make that task much easier, thereby speeding the adoption of Python 3. docutils illustrates how a more capable 2to3 would be useful. It's just one example of many. Yesterday I spent some time converting docutils to a common code base, so that it could be included without fuss in Leo's distro. I did this using the same technique that I initially used for Leo. I ran the *original* (Python 2.x) source on Python 3, and fixed the crashes as they arose :-) It only took a few hours to get docutils working, but there are obvious problems with this ad-hoc approach. Indeed, I could contemplate an ad-hock conversion "strategy" because the stakes are relatively small: if my port of docutils fails, a few Leo commands break. But this strategy is out of the question for David; the stakes are much higher for him. (Leo uses my port only as a fallback when Leo can't import an "official" version of docutils. This fallback is important, because docutils formats Leo's help commands.) Putting myself in David's place, I see why he sticks with the Python 2.x code base, and why he uses 2to3 to create Python 3.x sources as needed. However, this strategy has two drawbacks. As my experience shows, it definitely hinders people from using docutils on Python 3.x on Windows. This strategy also prevents distutils from moving to a Python 3 code base (or a common code base). As I thought about what David or I would need to do to do the job properly, I had a head-slapping moment. I haven't used 2to3 to create a common code base because 2to3 isn't designed for that. But it could be, and that would make a big difference! Later, I'll suggest how 2to3 could create a common code base automatically. First, let's see how David or I might *safely* create a common code base with the present 2to3. Step 1. Devise an *automated* way of using 2to3 to create a common code base. This depends on the distinction between: A. Code that will run on either 2 or 3 without change. B. Code that must be different depending on whether 2 or 3 is used. 'print' statements are an example of A (Python 2.6 and above). Changed import statements are an example of B. The most important instances of B are all changes related to unicode. The six package masks this distinction, which may or may not be an advantage, depending on your point of view. The A/B distinction divides the 2to3 fixers into two categories: The A fixers can be run *safely* to create a common code base. The B fixers cannot! For B fixers, we must switch code at run time. Last night I just tested sys.version_info < (3,0). Using six does the same indirectly. Step 2: Put the plan into motion. I haven't done this yet, but here is the plan: - Starting with a Python 2 code base, run *only* the A fixers to create a **halfway** code base. - Next, run the B fixers on the halfway base, *without* changing the halfway base, creating an **all-3** code base. - Somehow(!) merge the halfway and all-3 bases. The merge could involve adding tests for sys.version_info, or it could replace code with calls to six. Given the stakes, the merge must be automatic! I'll want to mark all merges with comments in the code itself. With this (untested) strategy in place, the corresponding changes in 2to3 become clear: 1. Incorporate the A/B distinction into 2to3. Give users options to run all A fixers, all B fixers or both A and B fixers. 2a. Allow B fixers to generate calls to six, or 2b. Allow B fixers to choose between 2 and 3 code at runtime using sys.version_info. The code need not be the cleanest, especially if the code is marked with comments. In short, relatively small changes to 2to3 might make it *much* easier to create common code bases. This might greatly speed the adoption of Python 3. Without an enhanced 2to3, I plan to create a script that will merge the halfway and all-3 code bases. I'll report my experience with the merge script when it materializes :-) Or maybe I'll hack 2to3... QQQQQ Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
