Martin v. Löwis schrieb:
Thomas Heller schrieb:
[I was talking about patches to make ctypes work on 64-bit windows]
I would prefer to merge these changes into release25-maint, because I want to also release the standalone ctypes packages from this branch (using it with svn:externals from somewhere else).
That's not a good reason for back-porting. If you want a "maintenance" branch for ctypes, feel free to create one in the subversion, likewise for tags.
OTOH, I can't comment on whether those changes would be acceptable for a backport to the 2.5 maintenance branch - if they don't introduce actual new features, it might be ok.
The official Python 2.5.x win64/AMD64 windows installers should still *not* contain the ctypes package, but they could install it separately.
I don't really understand. Are you planning to back-port PCbuild changes also? If so, how should including those extensions be suppressed?
Let me try to put it in different words. The official Python-2.5.amd64.msi does *not* contain ctypes, so the official Python-2.5.x.amd64.msi should also not contain ctypes (I assume). Not many people (I assume again) are running 64-bit windows, and use the 64-bit Python version - but that will probably change soon. I would like to merge the 64-bit windows related ctypes changes in trunk, as soon as I'm sure that they work, back into the release25-maint branch. And also make separate ctypes releases from the release25-maint source code. I will only backport these changes if I'm convinced that they do not change the functionality of tehe current code. This way win64 Python users could install ctypes from the separate release. Also this way the source code for ctypes in the separate and the Python bundled releases are exactly the same, without creating too much work because of the different repositories. Hope that makes the plan clear, Thomas