May I humbly suggest using IronPython as a first baby step?
It has the same syntax as CPython 2.6/2.7, but ALL text strings are in
unicode, just like in Python 3.x. 8-bit byte arrays must be declared
as such. I suspect that about half of the problems with Python 3
conversion will be in that very area.
To handle str vs unicode differences, I use...
<code>
def str2bytes(sval):
""" convert a string literal to a byte array """
if sys.version_info < (3,0) and isinstance(sval, str):
sval = sval.decode("latin1")
return sval.encode("latin1")
if sys.version[0] >= '3': #python 3.x
StringTypes = str
makeByteBuffer = bytes
memoryViewType = memoryview
_BaseException = Exception
else: #python 2.x
from exceptions import StandardError as _BaseException
memoryViewType = type(buffer(''))
makeByteBuffer = buffer
try: #jdhardy -- handle bytes under IronPython
bytes
except NameError:
bytes = str
StringTypes = (str,unicode) # will be messed up by 2to3 but never
used
</code>
Perhaps something in that same spirit should be adopted as a standard
"drop in" for modules which are being converted?
That would keep everyone doing such patches on the same page.
--
Vernon
On Sep 7, 12:01 am, Russell Keith-Magee <[email protected]>
wrote:
> On Sun, Sep 5, 2010 at 5:05 PM, VernonCole <[email protected]> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
