[issue10735] platform.architecture() gives misleading results for OS X multi-architecture executables

Ned Deily report at bugs.python.org
Sun Mar 13 08:49:37 CET 2011


Ned Deily <nad at acm.org> added the comment:

"IMHO the change to 'bits' is bogus, it is supposed to return the bit-size of the executable, not that of the currently running executable."

Perhaps but (1) the code currently does return the bit-size of the currently running executable if it can't parse the output from 'file'.  More importantly, (2) not surprisingly, platform.architecture was not designed to deal with the somewhat unusual case presented by OS X multi-architecture files that have multiple bit-sizes.

"I'd return all executable bitsizes in bits as '32bit', '64bit' or '32bit,64bit' (as appropriate) and only include the machine architectures in the linkage result."

That's another way to do it.  My thought was that, while the return values of "bits" and "linkage" are deliberately not specified in the documentation, "bits" is likely the more useful and used of the two and it would be useful to return upwardly compatible values while also providing the current bits of the running interpreter.  That's what most programs are really interested in since, AFAIK, in all other platforms and cases except OS X 64-/32- universal binaries, there can be no difference between the value for the interpreter and the executable file.  To me, adding the full set of values possible makes more sense to be returned in the linkage string rather than in bits.  And I still think it makes sense to have 'platform.architecture' be an officially blessed API to determine interpreter execution bit size, rather that the unintuitive sys.maxsize or struct.calcsize('P') tests. What led me to write this patch in the first place was that, on more than one occasion in support groups, I found people recommending testing platform.architecture(bits) to determine 32-bit vs 64-bit and it was clear that it was giving the wrong results in this case.

"And finally the executable file format is 'Mach-O', not 'Mach'."

As is, the patch returns "MachO".  The reason for doing that was to make parsing (both human and machine) of the platform string easier; it currently uses '-' as a separator for the various fields:
  $ python3.2 -m platform
  Darwin-10.6.0-i386-64bit
Dropping the '-' in 'Mach-O' was an easy and unambiguous way to continue to differentiate the fields without introducing any incompatibilities.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________


More information about the Python-bugs-list mailing list