[Python-Dev] FW: Fixing os.popen on Win32 => is the win32pipe stuff
going to be adopted?
M.-A. Lemburg
mal@lemburg.com
Wed, 08 Mar 2000 18:44:59 +0100
"Fred L. Drake, Jr." wrote:
>
> Guido van Rossum writes:
> > "it" == platform.py? Little interest from me personally; I suppose it
> > could go in Tools/scripts/...
>
> I think platform.py is pretty nifty, but I'm not entirely sure how
> it's expected to be used. Perhaps Marc-Andre could explain further
> the motivation behind the module?
It was first intended to provide a way to format a platform
identifying file name for the mxCGIPython project and then
quickly moved on to provide many different APIs to query
platform specific information.
architecture(executable='/usr/local/bin/python', bits='', linkage='') :
Queries the given executable (defaults to the Python interpreter
binary) for various architecture informations.
Returns a tuple (bits,linkage) which contain information about
the bit architecture and the linkage format used for the
executable. Both values are returned as strings.
Values that cannot be determined are returned as given by the
parameter presets. If bits is given as '', the sizeof(long) is
used as indicator for the supported pointer size.
The function relies on the system's "file" command to do the
actual work. This is available on most if not all Unix
platforms. On some non-Unix platforms and then only if the
executable points to the Python interpreter defaults from
_default_architecture are used.
dist(distname='', version='', id='') :
Tries to determine the name of the OS distribution name
The function first looks for a distribution release file in
/etc and then reverts to _dist_try_harder() in case no
suitable files are found.
Returns a tuple distname,version,id which default to the
args given as parameters.
java_ver(release='', vendor='', vminfo=('', '', ''), osinfo=('', '', '')) :
Version interface for JPython.
Returns a tuple (release,vendor,vminfo,osinfo) with vminfo being
a tuple (vm_name,vm_release,vm_vendor) and osinfo being a
tuple (os_name,os_version,os_arch).
Values which cannot be determined are set to the defaults
given as parameters (which all default to '').
libc_ver(executable='/usr/local/bin/python', lib='', version='') :
Tries to determine the libc version against which the
file executable (defaults to the Python interpreter) is linked.
Returns a tuple of strings (lib,version) which default to the
given parameters in case the lookup fails.
Note that the function has intimate knowledge of how different
libc versions add symbols to the executable is probably only
useable for executables compiled using gcc.
The file is read and scanned in chunks of chunksize bytes.
mac_ver(release='', versioninfo=('', '', ''), machine='') :
Get MacOS version information and return it as tuple (release,
versioninfo, machine) with versioninfo being a tuple (version,
dev_stage, non_release_version).
Entries which cannot be determined are set to ''. All tuple
entries are strings.
Thanks to Mark R. Levinson for mailing documentation links and
code examples for this function. Documentation for the
gestalt() API is available online at:
http://www.rgaros.nl/gestalt/
machine() :
Returns the machine type, e.g. 'i386'
An empty string is returned if the value cannot be determined.
node() :
Returns the computer's network name (may not be fully qualified !)
An empty string is returned if the value cannot be determined.
platform(aliased=0, terse=0) :
Returns a single string identifying the underlying platform
with as much useful information as possible (but no more :).
The output is intended to be human readable rather than
machine parseable. It may look different on different
platforms and this is intended.
If "aliased" is true, the function will use aliases for
various platforms that report system names which differ from
their common names, e.g. SunOS will be reported as
Solaris. The system_alias() function is used to implement
this.
Setting terse to true causes the function to return only the
absolute minimum information needed to identify the platform.
processor() :
Returns the (true) processor name, e.g. 'amdk6'
An empty string is returned if the value cannot be
determined. Note that many platforms do not provide this
information or simply return the same value as for machine(),
e.g. NetBSD does this.
release() :
Returns the system's release, e.g. '2.2.0' or 'NT'
An empty string is returned if the value cannot be determined.
system() :
Returns the system/OS name, e.g. 'Linux', 'Windows' or 'Java'.
An empty string is returned if the value cannot be determined.
system_alias(system, release, version) :
Returns (system,release,version) aliased to common
marketing names used for some systems.
It also does some reordering of the information in some cases
where it would otherwise cause confusion.
uname() :
Fairly portable uname interface. Returns a tuple
of strings (system,node,release,version,machine,processor)
identifying the underlying platform.
Note that unlike the os.uname function this also returns
possible processor information as additional tuple entry.
Entries which cannot be determined are set to ''.
version() :
Returns the system's release version, e.g. '#3 on degas'
An empty string is returned if the value cannot be determined.
win32_ver(release='', version='', csd='', ptype='') :
Get additional version information from the Windows Registry
and return a tuple (version,csd,ptype) referring to version
number, CSD level and OS type (multi/single
processor).
As a hint: ptype returns 'Uniprocessor Free' on single
processor NT machines and 'Multiprocessor Free' on multi
processor machines. The 'Free' refers to the OS version being
free of debugging code. It could also state 'Checked' which
means the OS version uses debugging code, i.e. code that
checks arguments, ranges, etc. (Thomas Heller).
Note: this functions only works if Mark Hammond's win32
package is installed and obviously only runs on Win32
compatible platforms.
XXX Is there any way to find out the processor type on WinXX ?
XXX Is win32 available on Windows CE ?
Adapted from code posted by Karl Putland to comp.lang.python.
> My biggest requirement is that it be accompanied by documentation.
> The coolness factor and shared use of hackerly knowledge would
> probably get *me* to put it in, but there are a lot of things about
> which I'll disagree with Guido just to hear his (well-considered)
> thoughts on the matter. ;)
The module is doc-string documented (see above).
This should server well as basis for the latex docs.
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/