[pywin32-checkins] py3k status

[Mark H. <mha...@sk...>]

> Argh! I'm still struggling with version control -- learning three at
> once. My personal & commercial stuff is on Bazaar so I only use CVS for
> pywin32 and am not too good with it. I intended that this checkin be
> applied to the py3k fork only.

My apologies for the short and cryptic message.  You did check in on the
py3k branch - I just wasn't clear.

[BTW - how are you finding bzr?  I'm working with them on a tortoise
implementation, but find windows support is a little lacking and they aren't
that motivated to help fix the niggles - eg, EOL support]

> I used python 2.6 for testing because I needed to import pythoncom and
> win32com, which work on 2.6 and I assumed were not yet ready on py3k.
> (If I had compiled them would they have worked?)

Let me explain what is happening:

Roger started the py3k work a long time ago, well before '2to3' was much use
at all.  The only practical way to proceed was to "fork" the .py code by
running it through 2to3 then fixing whatever broke.  (The C++ code is much
less of a problem - the pre-processor helps a lot there).  As a result, the
py3k branch has all .py code in py3k syntax.

I'm personally willing to take a lot of pain in the interests of *not*
forking the .py code.  The 2to3 tool has improved a lot and is now available
as a library.  Thus, the strategy I'm aiming for is to maintain all the code
in Python 2.x syntax, and use the 2to3 tool to convert the .py code at build
time.  This is slow, but still workable.

However, we aren't *quite* at the point where this works for Roger yet.  He
doesn't use 'setup.py' but still builds with the Visual Studio projects.  As
a result, his build process doesn't support the 2to3 conversion.  Further,
this means you simply can *not* have the pywin32 source tree on your
sys.path in py3k - you must convert to an intermediate directory (setup.py
handles this by converting to a temp directory, and these are written to
site-packages at install time)

So, I'm working towards my goal on a bzr branch -
lp:~mhammond/pywin32/py3k-integration - and this (mostly) works with *both*
2.3->2.7 and 3.0 from the same source tree.  Most of my work these days is
just merging and testing - the merging is working towards the following
goal:

* The py3k branch and the trunk should become identical in everything other
than .py code - but all such differences should be limited to 3.x specific
changes only (ie, all other 'modernizations' that work OK in 2.3 will be
merged to the trunk, leaving only the py3.x specifics)
* The bzr integration branch and the trunk should become identical in .py
code (implying all .py code is capable os successfully passing through 2to3)
* Once done, this implies all 3 will be identical, except for the .py code,
and those differences will be only in ways 2to3 can automatically handle.

Once we get to this point, hopefully Roger will be able to work with a 2to3
based build and the py3k branch will be able to be retired.  There is still
a fair bit to go to get there though - specifically in bytes and buffer
handling.

Getting back specifically to ado: this means that while making changes in a
2.6-only syntax is fine for the py3k branch, it will still leave me/us with
a future merge problem.  As we should be able to continue supporting py2.x
versions for a while, it makes the most sense for new versions to continue
to be developed in a Python 2.x syntax, and using 2to3, even manually in the
short term, to test on py3k.

I hope that clarifies things - please let me know if you have any concerns
or comments.  I'd be more than welcome to accept bundles/patches against the
bzr branch - even though that branch will also end up being thrown away, it
is currently useful in helping me merge.

Cheers,

Mark