The _ctypes extension module does currently not even build on Win64. I'm (slowly) working on this (for AMD64, not for itanium), but it may take a good while before it is stable - It is not even fully implemented currently. The win64 msi installer installs the ctypes package anyway, but it cannot be imported. I suggest that it should be removed from the 2.5 win64 msi installers, so that at least, when it is ready, can be installed as separate package. Thanks, Thomas
Thomas Heller schrieb:
I suggest that it should be removed from the 2.5 win64 msi installers, so that at least, when it is ready, can be installed as separate package.
Unfortunately, I won't be able to work on this until the release is made. Feel free to work on it, but I suggest to just not worry about it. There are many other problems with Win64 still, e.g. the test suite doesn't pass. Regards, Martin
Martin v. Löwis schrieb:
Thomas Heller schrieb:
I suggest that it should be removed from the 2.5 win64 msi installers, so that at least, when it is ready, can be installed as separate package.
Unfortunately, I won't be able to work on this until the release is made. Feel free to work on it, but I suggest to just not worry about it.
There are many other problems with Win64 still, e.g. the test suite doesn't pass.
And tons of compiler warnings, IIRC. If the state is still experimental, IMO it should be marked as such. Thomas
Thomas Heller schrieb:
There are many other problems with Win64 still, e.g. the test suite doesn't pass.
And tons of compiler warnings, IIRC. If the state is still experimental, IMO it should be marked as such.
Most of the compiler warnings are irrelevant for most of the applications, and some are bogus (in the sense that the code is perfectly fine as it stands). Not sure what "experimental" would mean; it normally means that it may change or may be abandoned as a failure. I don't think this is the case with this port (although I do want to drop IA-64 binaries in 2.6, due to lack of interest). If you think it means "has known bugs", then this applies to all Python releases on all target systems, ever (just look at the open bugs list). Regards, Martin
Martin v. Löwis wrote:
Thomas Heller schrieb:
There are many other problems with Win64 still, e.g. the test suite doesn't pass.
And tons of compiler warnings, IIRC. If the state is still experimental, IMO it should be marked as such.
Most of the compiler warnings are irrelevant for most of the applications, and some are bogus (in the sense that the code is perfectly fine as it stands).
Not sure what "experimental" would mean; it normally means that it may change or may be abandoned as a failure. I don't think this is the case with this port (although I do want to drop IA-64 binaries in 2.6, due to lack of interest).
If you think it means "has known bugs", then this applies to all Python releases on all target systems, ever (just look at the open bugs list).
Reasonable enough, but I suspect that Thomas' suggestion might save us from raising false hopes. I'd suggest that the final release announcement point out that this is the first release containing specific support for 64-bit architectures (if indeed it is), and that the developers would therefore expect a higher proportion of bug reports on this release to be associated with those platforms. Committed to fixing, blah blah blah ... regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden
Steve Holden schrieb:
Reasonable enough, but I suspect that Thomas' suggestion might save us from raising false hopes. I'd suggest that the final release announcement point out that this is the first release containing specific support for 64-bit architectures (if indeed it is)
It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess), and was released for Win64 throughout Python 2.4. ActiveState has been releasing an AMD64 package for some time now. Regards, Martin
[Steve Holden]
Reasonable enough, but I suspect that Thomas' suggestion might save us from raising false hopes. I'd suggest that the final release announcement point out that this is the first release containing specific support for 64-bit architectures (if indeed it is)
[Martin v. Löwis]
It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess), and was released for Win64 throughout Python 2.4. ActiveState has been releasing an AMD64 package for some time now.
Python has also been used on 64-bit Crays, and I actually did the first 64-bit port in 1993 (to a KSR Unix machine -- took less than a day to get it running fine! Guido's an excellent C coder.). Win64 is the first (and probably only forever more) where sizeof(long) < sizeof(void*), and that caused some Win64-unique pain, and may cause more. BTW, at least two of the people at the NFS sprint earlier this year were compiling and running Python on Win64 laptops. It's "solid enough", and surely nobody expects that Win64 users expect 100% perfection of anything they run <0.5 wink>.
Tim Peters wrote:
[Steve Holden]
Reasonable enough, but I suspect that Thomas' suggestion might save us from raising false hopes. I'd suggest that the final release announcement point out that this is the first release containing specific support for 64-bit architectures (if indeed it is)
[Martin v. Löwis]
It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess), and was released for Win64 throughout Python 2.4. ActiveState has been releasing an AMD64 package for some time now.
Python has also been used on 64-bit Crays, and I actually did the first 64-bit port in 1993 (to a KSR Unix machine -- took less than a day to get it running fine! Guido's an excellent C coder.). Win64 is the first (and probably only forever more) where sizeof(long) < sizeof(void*), and that caused some Win64-unique pain, and may cause more.
BTW, at least two of the people at the NFS sprint earlier this year were compiling and running Python on Win64 laptops. It's "solid enough", and surely nobody expects that Win64 users expect 100% perfection of anything they run <0.5 wink>.
I suppose we should be grateful thirteen years experience has gone into 64-bit support. I agree that "some breakage may occur" is true of any release and architecture though in the eyes of this lurker, at least, python-dev does a more-than-averagely conscientious job. It's going to be very interesting to see what comes out of the Google sprints. I am sure the 64-bitters will be out in force, so there'll be useful data about any such problems. <irony wink="0.97">64 bits is, I am sure, as much as anyone is ever going to need, so the pain will finally be over.</irony> It's good to see the idea of industry support for open source sprints taking off. Tomorrow, the world ... :-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden
On Aug 19, 2006, at 3:28 AM, Steve Holden wrote: ...
It's going to be very interesting to see what comes out of the Google sprints. I am sure the 64-bitters will be out in force, so there'll be
Hmmm, we'll be working on our laptops, as is typical of sprints, so I'm not sure how many 64-bit machines will in fact be around -- we'll see.
useful data about any such problems. <irony wink="0.97">64 bits is, I am sure, as much as anyone is ever going to need, so the pain will finally be over.</irony>
It's good to see the idea of industry support for open source sprints taking off. Tomorrow, the world ... :-)
Sprints are indeed a fascinating idea and have proven they work, in an open-source context -- I do wonder if they could be made to work in other contexts, and I'm sure many others are wondering similarly. Alex
On 8/21/06, Alex Martelli <aleaxit@gmail.com> wrote:
On Aug 19, 2006, at 3:28 AM, Steve Holden wrote: ...
It's going to be very interesting to see what comes out of the Google sprints. I am sure the 64-bitters will be out in force, so there'll be
Hmmm, we'll be working on our laptops, as is typical of sprints, so I'm not sure how many 64-bit machines will in fact be around -- we'll see.
FWIW, I have access to a pair of AMD64 machines with 16Gb RAM and several hundred Gb swap. I can't give anyone else access, but I can run tests and debug.
Sprints are indeed a fascinating idea and have proven they work, in an open-source context -- I do wonder if they could be made to work in other contexts, and I'm sure many others are wondering similarly.
We've had commercial, private "sprints" at XS4ALL for years, every 6 months or so, until last year. We didn't call them sprints and they obviously weren't as freeform as the Python sprints, but the concept was the same (as well as the atmosphere.) We stopped having them because the number of concurrent projects was consistently larger than the number of programmers, which makes the sprinting setup somewhat useless. -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Alex Martelli wrote:
Sprints are indeed a fascinating idea and have proven they work, in an open-source context -- I do wonder if they could be made to work in other contexts, and I'm sure many others are wondering similarly.
"war room" development and other colocation approaches are nothing new, and works very well in many contexts. </F>
On Sat, Aug 19, 2006 at 05:19:40AM -0400, Tim Peters wrote:
[Steve Holden]
Reasonable enough, but I suspect that Thomas' suggestion might save us from raising false hopes. I'd suggest that the final release announcement point out that this is the first release containing specific support for 64-bit architectures (if indeed it is)
[Martin v. L?wis]
It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess), and was released for Win64 throughout Python 2.4. ActiveState has been releasing an AMD64 package for some time now.
Python has also been used on 64-bit Crays, and I actually did the first 64-bit port in 1993 (to a KSR Unix machine -- took less than a day to get it running fine! Guido's an excellent C coder.). Win64 is the first (and probably only forever more) where sizeof(long) < sizeof(void*), and that caused some Win64-unique pain, and may cause more.
BTW, at least two of the people at the NFS sprint earlier this year were compiling and running Python on Win64 laptops. It's "solid enough", and surely nobody expects that Win64 users expect 100% perfection of anything they run <0.5 wink>.
It has always "just worked" for me on Opterons + Debian. Python 2.4 (#1, May 31 2005, 10:19:45) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.maxint 9223372036854775807
Thanks to the Alphas for making AMD64 on *nix a no-brainer, -Jack
On 8/19/06, Jack Diederich <jack@psynchronous.com> wrote:
It has always "just worked" for me on Opterons + Debian. Python 2.4 (#1, May 31 2005, 10:19:45) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.maxint 9223372036854775807
While that's certainly useful behaviour, it isn't exactly the same thing as the 64-bit support in Python 2.5. 64-bit longs have always worked (as Tim said, CPython is good C), but large parts of CPython were using ints instead of longs -- and I'm fairly certain there are still quite a few bugs with container types and more than 31-bits worth of elements. (I say that because I found more than I hoped for, writing the bigmem tests a few months back. And those tests only consider bytestrings, lists and tuples.) So, while sys.maxint doesn't change, and any container with sane amounts of elements will almost certainly work (one would hope that's tested enough by now), real-world code that actually uses, say, more than 100Gb worth of memory in a single container may still break. Unless we write more bigmem tests :> Luxury-problem-anyone?'ly y'rs, -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Martin v. Löwis wrote:
It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess)
make that "over a decade". the first Python system I built was on tru64, back in 1995 (portions of the the initial prototype was written on a 286 box under MS-DOS, but the bulk was developed on tru64 and deployed on tru64...) </F>
Fredrik Lundh <fredrik@pythonware.com> writes:
Martin v. Löwis wrote:
It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess)
make that "over a decade". the first Python system I built was on tru64, back in 1995 (portions of the the initial prototype was written on a 286 box under MS-DOS, but the bulk was developed on tru64 and deployed on tru64...)
Well, there's 64-bit support and then there's 64-bit support. While all Unix or Unix like OSs follow LP64 model, I believe Win64 follows a P64 model. So it's a whole new ball game. Ganesan -- Ganesan Rajagopal
Martin v. Löwis schrieb:
Thomas Heller schrieb:
I suggest that it [the ctypes package] should be removed from the 2.5 win64 msi installers, so that at least, when it is ready, can be installed as separate package.
Unfortunately, I won't be able to work on this until the release is made. Feel free to work on it, but I suggest to just not worry about it.
Patch for Tools\msi\msi.py uploaded, and assigned to you. http://python.org/sf/1545507 Thomas
Thomas Heller schrieb (this was before Python 2.5 had been released):
The _ctypes extension module does currently not even build on Win64.
I'm (slowly) working on this (for AMD64, not for itanium), but it may take a good while before it is stable - It is not even fully implemented currently.
The win64 msi installer installs the ctypes package anyway, but it cannot be imported.
I suggest that it should be removed from the 2.5 win64 msi installers, so that at least, when it is ready, can be installed as separate package.
Then, Martin changed the win64 msi installer to exclude the ctypes package when the _ctypes.pyd extension does not exist because it was not built. In the meantime I have integrated patches (in the trunk) so that _ctypes can be built for win64/AMD64, and does even work. Can these changes be merged into release25-maint? IMO this is low-risk because they contain only small changes to the files in Modules/_ctypes/libffi_msvc, plus *some* changes to support the Windows LP64 model. 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). The official Python 2.5.x win64/AMD64 windows installers should still *not* contain the ctypes package, but they could install it separately. Thanks, Thomas
[Resent after subscribing to python-dev with this new email address, sorry if it appears twice] Thomas Heller schrieb (this was before Python 2.5 had been released):
The _ctypes extension module does currently not even build on Win64.
I'm (slowly) working on this (for AMD64, not for itanium), but it may take a good while before it is stable - It is not even fully implemented currently.
The win64 msi installer installs the ctypes package anyway, but it cannot be imported.
I suggest that it should be removed from the 2.5 win64 msi installers, so that at least, when it is ready, can be installed as separate package.
Then, Martin changed the win64 msi installer to exclude the ctypes package when the _ctypes.pyd extension does not exist because it was not built. In the meantime I have integrated patches (in the trunk) so that _ctypes can be built for win64/AMD64, and does even work. Can these changes be merged into release25-maint? IMO this is low-risk because they contain only small changes to the files in Modules/_ctypes/libffi_msvc, plus *some* changes to support the Windows LP64 model. 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). The official Python 2.5.x win64/AMD64 windows installers should still *not* contain the ctypes package, but they could install it separately. Thanks, Thomas
Thomas Heller schrieb:
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? Regards, Martin
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
Thomas Heller schrieb:
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).
That would be good, yes.
Not many people (I assume again) are running 64-bit windows, and use the 64-bit Python version
I also agree.
- but that will probably change soon.
It speculation either way, but I disagree. It will take several years until people widely use Win64. For the foreseeable future, there are too many inconveniences to make it practical.
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.
I understand this. Still, integrating such changes formally introduces a new feature to the 2.5 branch (even though the feature isn't exposed readily). Whether or not this is ok is for the release manager to decide. What I don't understand is what the "64-bit windows related ctypes changes" are. Do they include changes to the PCbuild directory? Regards, Martin
participants (10)
-
"Martin v. Löwis" -
Alex Martelli -
Fredrik Lundh -
Ganesan Rajagopal -
Jack Diederich -
Steve Holden -
Thomas Heller -
Thomas Heller -
Thomas Wouters -
Tim Peters