if you want POSIX, import posix, not os

Charles G Waldman cgw at fnal.gov
Tue Aug 17 03:48:56 EDT 1999

Dan Connolly writes:
 > I have thought this was broken for years, but I just read
 > it again tonight, and I'm not going to pass over it in silence this
 > time:
 > "Do not import this module directly. Instead, import the module os,
 > which provides a portable version of this interface."
 > 	-- http://www.python.org/doc/1.5.2p1/lib/module-posix.html
 > I think this is terrible advice.

I think it's good advice.  If you're not using features like
"getpgrp", but more mundane things like "listdir", then 

import os

is highly portable (across Mac, Win, and Unix) whereas if you spelled

import posix

you'd be introducing a needlessly non-portable construction in your

It's up to you to read the documentation to know what are the
"generic" (always-available) operating system services and which ones
are platform-specific.  The "getpgrp" example you cite is one of the
latter...  if you use it, you  won't be able to get your code to run
on non-Unix platforms.  You have to resort to things like:

import os
if os.name = 'posix':
   pgrp = os.getpgrp()
   #something completely different

 > The os module is *not* portable:
 > "getpgrp () 
 >     Return the current process group id. Availability: Unix. "
 > 	-- http://www.python.org/doc/1.5.2p1/lib/os-procinfo.html

As the "Availability" comment implies, the os module implements a core 
set of functions, on top of which there are platform-specific
extensions.  If you're not on the right platform, you don't get the

 > A portable interface is one where I can expect consistent behaviour
 > of named objects across platforms, no?

Modulo the restrictions of "Availability"

 > The IEEE POSIX spec is widely implemented and understood.
 > When a program expects behaviour as specified in the POSIX
 > specs, it should say
 > 	import posix

If you make heavy use of the posix features this may make sense.  If
all you really need is things like listdir, getcwd, then it's

 > It would have made sense for python to define a really portable os
 > module, i.e. the least common denominator of the platforms it
 > runs on. But that's not what we've got.

No reason you can't create an "generic_os" module something like this:

from os import listdir,getcwd,path,name,remove,....

replacing "...." with the list of all functions which are supported on
ALL OS's where Python runs (or all OS's you care about).  A python
program which only imports "generic_os" and not "os" will be highly
portable, and also highly constrained in what it can do.

 > I hope the os module will be deprecated in future releases.

I don't think there is much chance of this happening, it it too widely 

More information about the Python-list mailing list