On Sun, Sep 5, 2010 at 5:05 PM, VernonCole <vernondc...@gmail.com> wrote: > "Once we're at a Django 2.6 minimum supported version, using 2to3 to > maintain > parallel implementations becomes a lot easier." > > As much as I admire Russ, and I do, I don't think that the above > statement is correct.
My apologies -- in the haste of getting a response out, I was a little lax in my choice of words. What you've described - i.e., * A single maintained 2.X source tree * An auto-generated 3.X source tree, * When 2.X support is dropped, the migration script is run one last time to migrate the source tree to be 3.X is pretty close to what I had in my head as the likely path. In practice, I'm sure there will be some complications, but we won't really know what they are until we get serious about 3.X support. > For a short time on the pywin32 team we tried to "maintain parallel > implementations" and found that it was a mistake we had to undo. The > correct approach is to maintain a SINGLE implementation -- in Python 2 > format -- and use 2to3 as a tool when the code happens to be running > on Python 3+. 2to3 should be run by distutils when it detects that > setup.py is being run by Python3. It should NOT be run manually by a > human. > > Then, some years in the future when the last Python 2.7 engine fades > away, you will run 2to3 once for the last time, and THEN maintain in > Python 3 format. You do NOT write your code with print() functions, > etc.. Simply roll any needed refactoring into the trunk at the > earliest opportunity, and make sure you don't break them during > maintenance. > > That's my advice from my experience. The code I am supporting runs on > any version of Python from 2.3 thru 3.1, including IronPython. It's good to know that there are people in the community that have done this in anger on other projects. If anyone can provide patches for refactors that are necessary in order to simplify the 3.X migration process, I'm happy to apply those patches -- and as I indicated, I already have applied a couple of patches for exactly this reason; for example changeset 13509 was to change the way we use sorting functions to avoid a keyword argument that has been deprecated for 3.X. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
