Python on Itanium Windows 64: available or planned?

[Bernhard Mulder]

I am using Python on Itanium Windows 64 (Server 2003) with a Win32 version.

Is there a native version available or planned? Are testers needed for
this platform?

Windows 64 is a bit unusual in that "long" is not large enough to hold
an address.

 

[Trent Mick]

[Bernhard Mulder wrote]

I am using Python on Itanium Windows 64 (Server 2003) with a Win32 version.

Is there a native version available or planned? Are testers needed for
this platform?

Python should compile fine for Win64. It was ported for Win64 a few
years back (around the time of Python 2.0/1.6 I think).

There are no free binary packages kicking around out there that I know
of but a number of people do compile it themselves for Win64. There was
some discussion on this list recently about how to do that seeing as
there is no DevStudio for Win64 (at least, that is my understanding).
One way was to export makefiles from Python's .dsp project files and use
the Win64 cross-compiler that is available with the platform SDK.

Windows 64 is a bit unusual in that "long" is not large enough to hold
an address.

Yup. Though I would use a stronger word than "unusual".

Trent

p.s. ActiveState will provide Win64 binary installers for Python on
contract, though I don't know if that is an option for you.

 

[Martin v. =?iso-8859-15?q?L=F6wis?=]

There are no free binary packages kicking around out there that I know
of but a number of people do compile it themselves for Win64.

However, there are free binary packages out there that you don't know
of

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python23.msi

See

http://groups.google.com/[email protected]

for the original announcement.

There was some discussion on this list recently about how to do that
seeing as there is no DevStudio for Win64 (at least, that is my
understanding).

Again, it depends: With sf.net/projects/vsextcomp, VS 7.1 is very well
capable of invoking the Itanium platform SDK compiler (AMD64 coming
soon).

Yup. Though I would use a stronger word than "unusual".

That may even be a source of bugs. I'm in the process of putting
size_t in every place Python currently uses "int" or "long" to store a
number of bytes. In some cases, exceeding 4GB (sometimes 2GB) will
cause crashes in Python 2.3 (in other cases, this is somewhat overkill
- eg. when the compiler complains that strlen(some_file_name) may not
fit into 4 bytes).

Regards,
Martin

 

[Mike Rovner]

That may even be a source of bugs. I'm in the process of putting
size_t in every place Python currently uses "int" or "long" to store a
number of bytes. In some cases, exceeding 4GB (sometimes 2GB) will
cause crashes in Python 2.3 (in other cases, this is somewhat overkill
- eg. when the compiler complains that strlen(some_file_name) may not
fit into 4 bytes).

Does that mean forthcoming API interface change?
There are mostly ints for sizes (ex. PyString_AsStringAndSize
(PyObject *obj, char **buffer, int *length)).

Regards,
Mike

 

[Martin v. =?iso-8859-15?q?L=F6wis?=]

Does that mean forthcoming API interface change?

Yes. I haven't changed any structure (yet), but, after approval on
python-dev, this is likely to happen as well.

There are mostly ints for sizes (ex. PyString_AsStringAndSize
(PyObject *obj, char **buffer, int *length)).

Indeed. I don't think it matters, though: processors typically return
results in registers. On a 64-bit processor, a single register will
take the result, and most likely, a 32-bit return value will be
widened appropriately. So you might actually get away with not
recompiling the extensions in 2.4 (atleast until ob_size changes,
which does cause incompatibilities on big-endian machines).

Regards,
Martin