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.10:37:07
SpamBayes Score 1.0837825e-10
Marked as misclassified No
Message-id <1241951830.86.0.45997319375.issue1578269@psf.upfronthosting.co.za>
In-reply-to
Content
I see now that symlink is defined in posixmodule.c (which ends up as the
builtin module 'nt').

Then, in os.py, there's a short section that does effectively 'from nt
import *'.

Would it be unreasonable for a patch to add a new Python module
(something like _nt_supplemental.py or platform_windows.py) which
exposes symlink() and islink(), and then in os.py to import those
functions into the os namespace at the same time as importing the
functions from the nt namespace?

My reasoning here is twofold:

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.
2) I don't want to clutter os.py with os-specific code.

This brings up two questions.

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.
2) Where would be a good location for the platform-specific pure-python
module?  If there's no guidance, I'll just pick something and it can be
relocated (as necessary) when the patch is applied.
History
Date User Action Args
2009-05-10 10:37:11jaracosetrecipients: + jaraco, lemburg, loewis, nnorwitz, jafo, giampaolo.rodola, swarren
2009-05-10 10:37:10jaracosetmessageid: <1241951830.86.0.45997319375.issue1578269@psf.upfronthosting.co.za>
2009-05-10 10:37:09jaracolinkissue1578269 messages
2009-05-10 10:37:08jaracocreate