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 loewis
Recipients giampaolo.rodola, jafo, jaraco, lemburg, loewis, nnorwitz, swarren
Date 2009-05-10.18:14:44
SpamBayes Score 5.6565863e-13
Marked as misclassified No
Message-id <4A071990.2000603@v.loewis.de>
In-reply-to <8B473FAE8A08C34C9F5666FD4B0A87B674F4908CD6@hornigold.jaraco.com>
Content
> Would you elaborate just a bit more on why a ctypes implementation would be
> undesirable?

ctypes is inherently insecure. It must be possible to use Python itself
with ctypes removed. Therefore, there is a strict policy not to use
ctypes in the core.

>> 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?

Correct - but for that to work, it should really only expose functions
that work on all systems. It currently fails to do so, allowing people
to write applications that they believe to be portable, but actually
aren't portable at all.

However, it has always been that way, so the added portability that the
os module provides is really minor. Instead, portability is already
provided in posixmodule.c
History
Date User Action Args
2009-05-10 18:14:46loewissetrecipients: + loewis, lemburg, nnorwitz, jafo, jaraco, giampaolo.rodola, swarren
2009-05-10 18:14:45loewislinkissue1578269 messages
2009-05-10 18:14:44loewiscreate