This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jaraco
Recipients giampaolo.rodola, jafo, jaraco, lemburg, loewis, nnorwitz, swarren
Date 2009-05-10.17:53:43
SpamBayes Score 2.7755576e-16
Marked as misclassified No
Message-id <8B473FAE8A08C34C9F5666FD4B0A87B674F4908CD6@hornigold.jaraco.com>
In-reply-to <4A070B08.7050808@v.loewis.de>
Content
> 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?
History
Date User Action Args
2009-05-10 17:53:45jaracosetrecipients: + jaraco, lemburg, loewis, nnorwitz, jafo, giampaolo.rodola, swarren
2009-05-10 17:53:43jaracolinkissue1578269 messages
2009-05-10 17:53:43jaracocreate