Jason R. Coombs <jar...@jaraco.com> added the comment: 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. ---------- title: Add os.link() and os.symlink() support for Windows -> Add os.link() and os.symlink() and os.path.islink() support for Windows _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1578269> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
