[Python-Dev] Reminder: last alphas next Wednesday 07-May-2008

Jeroen Ruigrok van der Werven asmodai at in-nomine.org
Fri May 2 09:46:01 CEST 2008


-On [20080502 07:57], Mark Hammond (mhammond at skippinet.com.au) wrote:
>The best way I can find for the win32 API to tell you this is a combination
>of the above and the IsWow64Process() (which returns True if you are a
>32bit process on a 64bit platform)

Support for IsWow64Process() is quite interesting in itself, so if you can
add support for that, cool. :)

>I'd be interested to know why you care though - ie, how will the behavior
>of your programs depend on that?

For Genshi I was mucking around with setuptools to create Windows eggs. My
machine at home is an AMD64 box. I have Python 2.5 installed, which is 64
bits on Windows x64.

On a normal Unix box an egg for a 32 bits system will result in something
like Genshi-0.5dev_r847-py2.5-linux-i686.egg. On an 64-bits system we get
Genshi-0.5dev_r847-py2.5-linux-x86_64.egg. This distinction is important
since Genshi includes a _speedups.so which is compiled to either 32 or
64-bits.

On a 64-bits Windows it will always create an egg with win32 in the name. So
both a 32-bits and 64-bits Python will in the end create an egg with win32.
So imagine creating a 64-bits egg with compiled _speedups and putting it on
PyPI. Any 32-bits Python requesting Genshi will get the egg with 64-bits
compiled binaries in it. I think it's obvious this is Not Good(tm). (I
already raised the issue on distutils-sig, but it has remained unanswered
thus far.)

So from what I gather we have no unique way to refer to 32-bits or 64-bits
Python aside from the semi-adequate platform.architecture()[0].

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Be yourself is all that you can do.


More information about the Python-Dev mailing list