if you want POSIX, import posix, not os
fredrik at pythonware.com
Tue Aug 17 09:23:06 CEST 1999
Dan Connolly <connolly at w3.org> wrote:
> 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
> "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.
> The os module is *not* portable:
in fact, the "os" module docs says:
This module provides a more portable way of using
operating system (OS) dependent functionality than
importing an OS dependent built-in module like posix
note the use of "more" in that sentence.
> If an implementation on WinNT provides posix semantics,
> then it may supply a module by that name that works as
how about partial posix semantics? (like Windows offers,
which happens to be the most widespread target platform
we have today). hey, maybe the best solution is to offer
that under a different name? (hmm, isn't that how it's
and how to deal with optional features? like chown, exec*,
fork, ftruncate, getcwd, getegid, geteuid, getgid, getpgrp,
getppid, getuid, kill, link, mkfifo, nice, pipe, plock, popen,
putenv, readlink, setgid, setpgid, setpgrp, setsid, setuid,
strerror, symlink, system, tcgetpgrp, tcsetpgrp, times,
uname, wait, and waitpid, one or more of which are not
supported by all "mostly posixish" unix flavours. hey, maybe
the best solution is to offer some way to test which of these
are available? (wait, isn't that the case today?)
> Otherwise, I want an early ImportError, not
> later AttributeErrors, or worse: silent failures to
> behave as specified.
# platform profile: list functions required by this
# module, so we get early errors
os.getpgrp, os.foo, os.bar
> 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.
> I hope the os module will be deprecated in future releases.
umm, so if it doesn't implement 100% of what YOU happen
to want from it, NOBODY should be allowed to use it. that's
cool, but maybe somewhat impractical for the
rest of us ;-)
(fwiw, while I'm not all that surprised to here this from
people in your domain <0.5 wink>, history has showed
that it's a doomed approach:
More information about the Python-list