Py_CreateSymbolicLinkW can be removed in 3.5+ because Windows XP is no longer supported and calling enable_symlink() is pointless. 

The Windows API uses some privileges simply to determine which security principals can access a capability. Whether the privilege is currently enabled or disabled in the current access token doesn't matter because functions automatically enable it for the current thread (in an impersonation token). 

In this case, CreateSymbolicLink calls RtlAcquirePrivilege to enable SeCreateSymbolicLinkPrivilege for the current thread; sets the symlink reparse point; and then reverts the current thread via RtlReleasePrivilege. It goes through these same steps whether or not the privilege is already enabled in the process, so there's no chance of a race condition between competing threads.

Also, as a side note, the linked blog makes the following claim, which paints an incomplete picture:

> However, for Windows users, due to Windows Vista’s security 
> requirements, users needed local admin rights and, importantly, 
> had to run mklink in a command-line console elevated as 
> administrator to create/modify symlinks. 

SeCreateSymbolicLinkPrivilege can be added to a standard user account, and it doesn't get filtered out from the user's token. So in general you do not need administrator access. However, the above is describing the case for most developers, who use a administrator account that's subject to UAC restrictions.