if you want POSIX, import posix, not os

[Dan Connolly]

Charles G Waldman wrote:
> 
> 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
> files=os.listdir(os.getcwd())
> 
> is highly portable (across Mac, Win, and Unix) whereas if you spelled
> it
> 
> import posix
> files=posix.listdir(posix.getcwd())
> 
> you'd be introducing a needlessly non-portable construction in your
> code.

But that's not what it says. It says that even if you want
to call stuff that's only available on POSIX platforms,
you should import os rather than posix.

Let's have a module with things like listdir
and getcwd in it, and leave getpwent() completely out of it.

Or at least: document getpwent() under posix, and make a
note by getcwd(), listdir() etc. that says "these are also available
via the os module, which is portable."

> 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()
> else:
>    #something completely different

Why is that better than:

try:
  import posix
except:
  # something completely different

Your code example reminds me of pre-OOP code like:
	if shapeName='circle':
		... draw circle on canvas ...
	elif shapeName='square':
		... draw square
	...


>  > 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
> extensions.

Why glom this into one module? What's the benefit over
having aa well-defined cores set of functions in one module,
and extensions in modules like posix, Win32, etc?

Most of all: why document getpwent() under the os module rather
than under posix?

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

Why mess with availability at all? What does it help?


>  > 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
> overkill.
> 
>  > 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:
> 
> ----generic_os.py-----
> 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.

Gee... sounds awfully useful; in fact, it sounds a lot more
useful than the current os module. But it's not very useful
if I have to make it up myself, since the purpose of such
a module is that the other programmers in the community
can recognize generic_os.listdir() as a well-known idiom.

>  > 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
> used.

How about attempting to change that trend? i.e. how about
in stead of documenting os.getpgrp() with an availability
caveat, the os module documentation only lists the stuff
that's really expected to be portable, and has a note
at the bottom ala:

	the os module may contain other implementation-defined
	objects; for example, on posix platforms, the contents
	of the posix module are shadowed in the os module.
	[... list the other cases ...]

-- 
Dan Connolly, W3C
http://www.w3.org/People/Connolly/