Ned Deily <n...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue10735>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
