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 amaury.forgeotdarc, brian.curtin, eric.smith, jaraco
Date 2010-12-03.20:01:54
SpamBayes Score 1.2029266e-13
Marked as misclassified No
Message-id <1291406516.43.0.73689301496.issue9333@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks and good work, Brian.

I think ,though, I'm leaning toward agreeing with Amaury on the presence of the symlink attribute in os.

I can easily see the justification for hiding it in legacy environments (Windows XP & Server 2003), where the relevance diminishes over time, but since we're talking about Python 3, with limited adoption, I'm inclined to suggest it's better to err on the side of breaking existing code and getting the code right, rather than backward compatibility.

To me, the test `hasattr(os, 'symlink')` does not effectively communicate the nuances of the underlying functionality. It doesn't provide a run-time environment any data on why it may or may not be present.

While it does provide excellent backward compatibility (based on a survey of use-cases), I worry it's not the best solution, and might be undesirable in the long run.

Would it be possible to provide a `can_symlink` or `user_can_symlink` function which would be recommended to replace the `hasattr` test? Perhaps we consider keeping the current implementation, deprecate the use of the hasattr test, and prepare for a change in 3.3 or 3.4 where the symlink method is always present on Windows systems >= 6.0.

I defer to Brian's opinion on this, but did want to share my mild discomfort with the current implementation.
History
Date User Action Args
2010-12-03 20:01:56jaracosetrecipients: + jaraco, amaury.forgeotdarc, eric.smith, brian.curtin
2010-12-03 20:01:56jaracosetmessageid: <1291406516.43.0.73689301496.issue9333@psf.upfronthosting.co.za>
2010-12-03 20:01:55jaracolinkissue9333 messages
2010-12-03 20:01:54jaracocreate