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

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

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 8/21/06, Alex Martelli 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 Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

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

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>

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

[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

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