源码:
global __file__
__file__=os.path.abspath(__file__)
if os.path.islink(__file__):
__file__=getattr(os,'readlink',lambda x:x)(__file__)
问题：
1.os.path.islink的作用是什么？
2.os.readlink 为什么有可能不存在呢？要使用getattr来返回这个os模块的操作，对没有定义这个操作的情况是什么呢？
对于1.查help中为
os.path.islink(path)
Return True if path refers to a directory entry that is a symbolic link. Always False if symbolic links are not supported.
新问题：a symbolic link是什么文件呢？是快捷方式吗？有不支持快捷方式的os？
查到的结果中http://stackoverflow.com/questions/15258506/os-path-islink-on-windows-with-python中有了详细的解释，原来这个方法本身在
2.7版本之后做过bug修改的，原文说：
One of those features is handling NTFS symlinks. That functionality was added in 3.2 in late 2010. (See the 3.2, 3.1, and 2.7
source for details.)
上面源码中是用的是python27版本
查了这个bug的官方描述为http://bugs.python.org/issue13143
ok现在的问题是NTFS symlinks 与 symbolic link 的关系，子集？还有就是他们到底是what？
在这个http://hi.baidu.com/xiayang/item/9f29e7112f5433eb9913d622 中终于有了答案，原文如下：
"NTFS同样具有Linux早就使用的Hard Link和Soft Link功能...
Soft Link在微软的NTFS里头有另一个名 字：symbolic link（符号链接）。它类似于Windows里头常用的.lnk快捷方式，但是微软也同样给出了限
制：symbolic link只能应用于文件夹（包括卷），但可以跨分区使用（可以在D盘生成一个指向C盘某文件夹的symbolic link）。如 果需要创建文
件的symbolic link，那就请使用.lnk吧。
而文件夹的symbolic link效果和.lnk差不 多，symbolic link本身是一个文件，用户一旦访问symbolic link的话就会自动跳转（Reparse）到目标
文件夹，不过 和.lnk不同的是，symbolic link是底层文件系统里头实现，对用户和程序透明——例如，文件夹B是文件夹A的symbolic link， 那
么程序访问B时就和访问A完全一样，就好像A里头的全部东西都改了路径到B下面了。不过相应的，如果你删除symbolic link（文件夹B）里头 的某
个文件，文件夹A里头相应的文件也会被删除的。2k/XP的Explorer似乎也对symbolic link支持不足，删除 symbolic link本身好像也会删除A……
symbolic link有什么用？如果你的系统盘满了，或者空间不足以让某些程序 运行时，就可以把一些在系统盘里头的文件夹移动到其他分区，然后
制造一个symbolic link，这样既可以腾出空间，也可以让其他程序不至于出错。 另外由于它基于NTFS文件系统，因此在一个操作系统生成的
symbolic link也同样能被另一个操作系统识别。
虽然微软没有推广 symbolic link，但是其实在2000已经开始有使用symbolic link了。
如果我们加载一个NTFS卷/分区，磁盘管理器会 提示盘符或者是否装载到某个NTFS文件夹，选择后者其实就是生成一个指向该卷/分区的symbolic
link "
wiki中给出的解释更为详细（symbolic_link http://en.wikipedia.org/wiki/Symbolic_link）
这样if os.path.islink(__file__)就是判断给出的__file__如果是symbolic link地址的话要处理一下的意思，处理成什么呢？猜想一下啊，应该
是改写为真实的原始地址吧？！
2.
首先getattr是个很棒的自省函数（参见http://woodpecker.org.cn/diveintopython/power_of_introspection/getattr.html），但问题是在这里
是os.readlink 不支持者但依然使islink为true的会是谁呢？
这次查询help直接得出结果
Return a string representing the path to which the symbolic link points. The result may be either an absolute or relative
pathname; if it is relative, it may be converted to an absolute pathname using os.path.join(os.path.dirname(path), result).
Changed in version 2.6: If the path is a Unicode object the result will also be a Unicode object.
Availability: Unix.
这个os.readlink 是unix专用的，那么1中islink判断的windows中的ntfs下的symbolic link就使用 lambda x:x 了 ok，以上help用的都是2.7的官
方帮助，
查询了一下python3.2的如下
Availability: Unix, Windows
Changed in version 3.2: Added support for Windows 6.0 (Vista) symbolic links.
ok，自己查看的源程序指定版本是python27了，一直没太留心python3的内容，改进东西不少啊：）
global __file__
__file__=os.path.abspath(__file__)
if os.path.islink(__file__):
__file__=getattr(os,'readlink',lambda x:x)(__file__)
问题：
1.os.path.islink的作用是什么？
2.os.readlink 为什么有可能不存在呢？要使用getattr来返回这个os模块的操作，对没有定义这个操作的情况是什么呢？
对于1.查help中为
os.path.islink(path)
Return True if path refers to a directory entry that is a symbolic link. Always False if symbolic links are not supported.
新问题：a symbolic link是什么文件呢？是快捷方式吗？有不支持快捷方式的os？
查到的结果中http://stackoverflow.com/questions/15258506/os-path-islink-on-windows-with-python中有了详细的解释，原来这个方法本身在
2.7版本之后做过bug修改的，原文说：
One of those features is handling NTFS symlinks. That functionality was added in 3.2 in late 2010. (See the 3.2, 3.1, and 2.7
source for details.)
上面源码中是用的是python27版本
查了这个bug的官方描述为http://bugs.python.org/issue13143
ok现在的问题是NTFS symlinks 与 symbolic link 的关系，子集？还有就是他们到底是what？
在这个http://hi.baidu.com/xiayang/item/9f29e7112f5433eb9913d622 中终于有了答案，原文如下：
"NTFS同样具有Linux早就使用的Hard Link和Soft Link功能...
Soft Link在微软的NTFS里头有另一个名 字：symbolic link（符号链接）。它类似于Windows里头常用的.lnk快捷方式，但是微软也同样给出了限
制：symbolic link只能应用于文件夹（包括卷），但可以跨分区使用（可以在D盘生成一个指向C盘某文件夹的symbolic link）。如 果需要创建文
件的symbolic link，那就请使用.lnk吧。
而文件夹的symbolic link效果和.lnk差不 多，symbolic link本身是一个文件，用户一旦访问symbolic link的话就会自动跳转（Reparse）到目标
文件夹，不过 和.lnk不同的是，symbolic link是底层文件系统里头实现，对用户和程序透明——例如，文件夹B是文件夹A的symbolic link， 那
么程序访问B时就和访问A完全一样，就好像A里头的全部东西都改了路径到B下面了。不过相应的，如果你删除symbolic link（文件夹B）里头 的某
个文件，文件夹A里头相应的文件也会被删除的。2k/XP的Explorer似乎也对symbolic link支持不足，删除 symbolic link本身好像也会删除A……
symbolic link有什么用？如果你的系统盘满了，或者空间不足以让某些程序 运行时，就可以把一些在系统盘里头的文件夹移动到其他分区，然后
制造一个symbolic link，这样既可以腾出空间，也可以让其他程序不至于出错。 另外由于它基于NTFS文件系统，因此在一个操作系统生成的
symbolic link也同样能被另一个操作系统识别。
虽然微软没有推广 symbolic link，但是其实在2000已经开始有使用symbolic link了。
如果我们加载一个NTFS卷/分区，磁盘管理器会 提示盘符或者是否装载到某个NTFS文件夹，选择后者其实就是生成一个指向该卷/分区的symbolic
link "
wiki中给出的解释更为详细（symbolic_link http://en.wikipedia.org/wiki/Symbolic_link）
这样if os.path.islink(__file__)就是判断给出的__file__如果是symbolic link地址的话要处理一下的意思，处理成什么呢？猜想一下啊，应该
是改写为真实的原始地址吧？！
2.
首先getattr是个很棒的自省函数（参见http://woodpecker.org.cn/diveintopython/power_of_introspection/getattr.html），但问题是在这里
是os.readlink 不支持者但依然使islink为true的会是谁呢？
这次查询help直接得出结果
Return a string representing the path to which the symbolic link points. The result may be either an absolute or relative
pathname; if it is relative, it may be converted to an absolute pathname using os.path.join(os.path.dirname(path), result).
Changed in version 2.6: If the path is a Unicode object the result will also be a Unicode object.
Availability: Unix.
这个os.readlink 是unix专用的，那么1中islink判断的windows中的ntfs下的symbolic link就使用 lambda x:x 了 ok，以上help用的都是2.7的官
方帮助，
查询了一下python3.2的如下
Availability: Unix, Windows
Changed in version 3.2: Added support for Windows 6.0 (Vista) symbolic links.
ok，自己查看的源程序指定版本是python27了，一直没太留心python3的内容，改进东西不少啊：）
没有评论:
发表评论