tangent to original topic: > Last night I just tested sys.version_info < (3,0).
I just learned this last night, using `sys.hexversion` is a simpler method to determining one's place in the python version lineage, albeit with an extra mental parsing load for the minor version numbers and patch levels. http://stackoverflow.com/questions/1093322/how-do-i-check-what-version-of-python-is-running-my-script if sys.hexversion < 0x03000000: from urllib2 import urlopen # python 2 or less else: from urllib.request import urlopen # python 3+ On Tue, Apr 16, 2013 at 10:12 AM, Edward K. Ream <[email protected]>wrote: > 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. > > > -- 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.
