[Python-Dev] Updates to PEP 471, the os.scandir() proposal (original) (raw)

Tim Delaney timothy.c.delaney at gmail.com
Thu Jul 10 09:35:19 CEST 2014

On 10 July 2014 17:04, Paul Moore <p.f.moore at gmail.com> wrote:

On 10 July 2014 01:23, Victor Stinner <victor.stinner at gmail.com> wrote: >> As a Windows user with only a superficial understanding of how >> symlinks should behave, (...) > > FYI Windows also supports symbolic links since Windows Vista. The > feature is unknown because it is restricted to the administrator > account. Try the "mklink" command in a terminal (cmd.exe) ;-) > http://en.wikipedia.org/wiki/NTFSsymboliclink > > ... To be honest, I never created a symlink on Windows. But since it > is supported, you need to know it to write correctly your Windows > code.

I know how symlinks do behave, and I know how Windows supports them. What I meant was that, because Windows typically makes little use of symlinks, I have little or no intuition of what feels natural to people using an OS where symlinks are common. As someone (Tim?) pointed out later in the thread, FindFirstFile/FindNextFile doesn't follow symlinks by default (and nor do the dirent entries on Unix).

It wasn't me (I didn't even see it - lost in the noise).

So whether or not it's "natural", the "free" functionality provided by the OS is that of lstat, not that of stat. Presumably because it's possible to build symlink-following code on top of non-following code, but not the other way around.

For most uses the most natural thing is to follow symlinks (e.g. opening a symlink in a text editor should open the target). However, I think not following symlinks by default is better approach for exactly the reason Paul has noted above.

Tim Delaney -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140710/20b8f992/attachment.html>

More information about the Python-Dev mailing list