>> > os.machine == 'i386' > > It should be platform.machine, not os.machine. > >> Haven't seen a '386 for over ten years.. Intel have standardised >> to calling everything 'Pentium' pretty much since at least 2000. > > Irrelevant:
I don't see how it is irrelevent that the constants don't map to any 'real' machines on the market. > The platform module has been around in Python for quite some time. > Too bad you haven't noticed it yet. Actually I do know about it. But I was only commenting about the PEP as it stands. >> imho 'win32' is a really confusing term. That implies that it won't >> work on 64bit. When in fact it mostly will. > > No, it implies that the test will be true on all systems where the > platform value in the sys module will be win32. That *also* has > been around for ages (ever since Python started, basically). I know that you know that. But people without the programming legacy that you do can't be expected to know that. > Whereas using the built-in platform identification mechanism > would be extremely difficult? The problem is that you can't buy any machine from the shop called 'darwin'. You can't buy any notebook/desktop new machine with an i386 processor in it. Any new kid can't buy a darwin or an i386 notebook. We don't use "steam-train" to denote an "ICE" train. It is just not right. Sorry. The module is flawed and doesn't reflect the real world. Why build a new PEP upon a module with errors? It doesn't make sense. But this is just the start. I'll outline more problems to come. Starting new PEPs based on erroneous system APIs? Sorry I think that is lower than your normallly incredibly high standard of workmanship. David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig