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.17:12:42
SpamBayes Score 8.465728e-12
Marked as misclassified No
Message-id <>
In-reply-to <>
> Would it be unreasonable for a patch to add a new Python module
> (something like or which
> exposes symlink() and islink(), and then in to import those
> functions into the os namespace at the same time as importing the
> functions from the nt namespace?

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

> 1) I don't want to additionally complicate posixmodule.c, and since
> Windows doesn't have a posix symlink function, this doesn't seem like
> the appropriate place anyway.

Don't worry about that. The purpose of posixmodule.c is to be

> 1) Is there a problem with the os module exposing names that aren't in
> posixmodule.c, but are platform-specific?  I suspect not, but I want to
> consider the possibility.

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.

> 2) Where would be a good location for the platform-specific pure-python
> module?

See above. There can't be such a thing.
Date User Action Args
2009-05-10 17:12:45loewissetrecipients: + loewis, lemburg, nnorwitz, jafo, jaraco, giampaolo.rodola, swarren
2009-05-10 17:12:43loewislinkissue1578269 messages
2009-05-10 17:12:42loewiscreate