> How would you provide access to the system functions in pure Python?
> If you think of using ctypes, then yes, that would be unreasonable.

Would you elaborate just a bit more on why a ctypes implementation would be 
undesirable?  "What's New" for Python 2.5 states that "Perhaps developers will 
begin to write Python wrappers atop a library accessed through ctypes instead 
of extension modules, now that ctypes is included with core Python."  I 
acknowledge that because we're talking about the core, the use of ctypes may 
be discouraged, but I have no strong reasons to think so.  I can see for 
consistency sake that it might be preferable to call the Windows C APIs 
directly, but that to me seems like unnecessary complication and maintenance 
trouble, whereas ctypes abstracts the exact same library calls in a 
compiler-agnostic way.  In my experience, ctypes has been invaluable providing 
robust and clean interfaces to otherwise unexposed APIs. As you can see in 
jaraco.windows.filesystem, I was able to implement link(), islink(), and 
symlink() in just a few dozen lines of Python.  It seems like unnecessary work 
to port this to CPython APIs surrounded by ifdefs and potentially introducing 
new compiler issues.

So, to be clear, I don't have the experience to assert that a ctypes 
implementation is a proper one, but I have little reason to think otherwise 
and would very much appreciate a little guidance on why I wouldn't want to use 
ctypes given the positive experiences I've had thus far.

> Don't worry about that. The purpose of posixmodule.c is to be
> system-specific.

After your answer, I suspect this will be the approach I'll take.

> In general, the os module shouldn't expose any functions that are
> platform-specific. That's the whole point of the os module.
>
> People tend to access functions of the posix module that are specific
> to POSIX through the os module, but it isn't really meant this way.

But isn't that the way to write future-proof portable code?  If one writes 
code that calls os.symlink, and a future version of Python supports symlink in 
Windows, then the library that calls os.symlink may just work in Windows 
without any rewrite.  Indeed, isn't that the primary purpose of the os module, 
to provide a unified interface to platform-specific implementations of the 
same behavior?