Everybody's right in this debate. I have to type a lot to express objectively my opinion, but better filter my reasoning and just say the conclusion. Having in mind: - what POSIX is - what an OS is - that an OS may or may not comply w/ the POSIX standard, and if it doesn't, it may do so in a couple of years (Windows 3K and PyOS come to mind ;-) - that the os module claims portability amongst the different OSes, mainly regarding their filesystem & process management services, hence it's exposing only a *subset* of the os specific services - the current state of Python It would be nice: - to leave the os module as a common denominator - to have a "unix" module (which could further incorporate the different brands of unix) - to have the posix module capture the fraction of posix functionality, exported from a particular OS specific module, and add the appropriate POSIX propaganda in the docs - to manage to do this, or argue what's wrong with the above -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

From: "Gordon McMillan"

Jack Jansen wrote:

...

There's one slight problem with this: when you use functionality that is partially portable, i.e. a call that is available on Windows and Unix but not on the Mac.

It gets worse, I think. How about the inconsistencies in POSIX support among *nixes? How about NT being a superset of Win9x? How about NTFS having capabilities that FAT does not? I'd guess there are inconsistencies between Mac flavors, too.

The Java approach (if you can't do it everywhere, you can't do it) sucks. In some cases you could probably have the missing functionality (in os) fail silently, but in other cases that would be a disaster.

The Python policy has always been "if it's available, there's a standard name and API for it; if it's not available, the function is not defined or will raise an exception; you can use hasattr(os, ...) or catch exceptions to cope if you can live without it." There are a few cases where unavailable calls are emulated, a few where they are made no-ops, and a few where they are made to raise an exception uncoditionally, but in most cases the function will simply not exist, so it's easy to test. --Guido van Rossum (home page: http://www.python.org/~guido/)