[Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
"Martin v. Löwis"
martin at v.loewis.de
Sat Mar 18 23:18:50 CET 2006
Fernando Perez wrote:
> So I think M.A. is right on the money here with his statement. Unless you
> consider the Linux/64bit camp insignificant. But if that is the case, it
> might be worth putting a big statement in the 2.5 release notes indicating
> "there is a good chance, if you use third party extensions and a 64 bit OS,
> that this won't work for you". Which will mean that a fraction of the
> scientific userbase (a big, enthusiastic and growing community of python
> users) will have to stick to 2.4.
It's more intricate than that. If certain extensions are of interest to
the scientific community, I certainly expect the authors of them to fix
However, to "fix" the extension can still be done in different levels:
you can easily fix it to not crash, by just honoring all compiler
warnings that gcc produces. That doesn't mean you fully support
Py_ssize_t, since you might not support collections with more than
2**31 elements. In these cases, the extension will not crash, but it
will compute incorrect results if you ever encounter such a collection.
Even on all these AMD64 Linux machines, this is still fairly unlikely,
since you need considerably more than 16GiB main memory to do something
useful on such collections - very few machines have that much memory
today. Again, people that have such machines and need to run Python
programs with that many data need to make sure that the extensions
work for them. Sticking with 2.4 is no option for these people, since
2.4 doesn't support such large collections, anyway.
To really fix such extensions, I recommend building with either
Microsoft C or Intel C. The Microsoft compiler is available free
of charge, but runs on Windows only. It gives good warnings, and
if you fix them all (in a careful way), your code should fully
support 64 bits. Likewise for the Intel compiler: it is available
for free only for a month, but it runs on Linux as well.
OTOH, I'm still doubtful how many extensions will be really affected
by the change in the first place. Your code *breaks* with the change
only if you implement the sequence or buffer protocols. I'm doubtful
that this is an issue for most applications, since many extensions
(I believe) work without implementing these protocols.
More information about the Python-Dev