哈哈哈，还是看源码吧

【 在 pcal 的大作中提到: 】
: 想在build_ext 命令中加点自定义的操作，看了官方文档还是一头雾水。那个文档真是乱七八糟
--
FROM 223.104.212.*

下次可以手动把库复制一份出来改了跑跑看。
我对pip，scons，gyp都是这样处理的。
看代码比看英语+DSL容易得多。

【 在 pcal 的大作中提到: 】
: 弄好了。看了三份代码
--
FROM 223.104.212.*

说得是！

【 在 lhawk 的大作中提到: 】
: python的文档严谨程度差Java十条街，估计就是毛子猛糙快的风格
: 刚学python想搞清楚file object到底有哪几个方案，愣是没找到，很多地方说file object，
: 如此基础的知识就没有一篇文档给你讲清楚file object到底有哪几个API，只能看代码。
: ...................
--
FROM 223.104.212.*

help(f)也可以用
f?
f.open?

但python的文档真的不如java,qt之类的。

【 在 lvsoft 的大作中提到: 】
: 启动ipython
: f=open('foo')
: help(f)
: 完事
: python是可以自省的，习惯不了还是老老实实去用“严谨的”java吧。
: python和java果然尿不到一个壶里面去。
--
FROM 101.84.182.*

查个文档还需要命令行，还需要先知道这个语法，要不然就没法查文档？
而且你这个代码一上来就报错，况且就算按照你说的执行了，出来的也不一定是所谓的file object的文档啊

Help on TextIOWrapper object:

class TextIOWrapper(_TextIOBase)
......

到底file object是个什么鬼，有地方写清楚了吗？
查文档除了一开始不会需要看帮助，还有一种情况是明确知道contract，现在连一个明确的说明都没有，想做一个duck type支持file object到底要支持哪些方法才能用？不知道不明确？
和中医一个套路，副作用不明确？
geek自己玩没问题，工程上这种搞法，且不说GIL执行效率，这种到处稀里糊涂缺乏contract的思维，只能到处埋坑，前任挖坑坑后人呗。

【 在 lvsoft 的大作中提到: 】
: 启动ipython
: f=open('foo')
: help(f)
: ...................
--
FROM 123.124.235.*