Email Archive: pywin32-checkins (read-only)
|
[pywin32-checkins] py3k status
From: Mark Hammond <mhammond@sk...> - 2008-11-14 01:37
|
|
> 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 |
Thread View
| Thread | Author | Date | |
|---|---|---|---|
| [pywin32-checkins] pywin32/adodbapi adodbapi.py,1.2.2.1,1.2.2.2 | Vernon Cole <kf7xm@us...> |
|
|
|
|
|
