请问一下PYTHON有没有和JAVA一样的API介绍的文档啊

flw

原帖由 jkit 于 2006-6-15 10:20 发表


我说的是方不方便的问题，不是知不知道的问题。

我的意思是说打包过的chm要比html用起来方便。html版的javadoc就已经够方便了，而pydoc要打包成chm才能凑合用，我啥时候说没有html版的pydoc了？你觉 ...

嗯，先构思再写代码听起来似乎真的很酷，
不过，程序员不是用来摆酷用的。
不管是边写代码边思考，还是思考好了再写代码，
都不重要，重要的是用最短的时间拿出最好的东西。

秀才造反，十年不成。
由此可见，有时候并不是空想就能把问题全都想完，然后再动手做就一点障碍都没有。

BTW：你刚才说：
纯html文件的javadoc我觉得就已经很好用了，因为它层次分明，很容易找到想要的文档，根本就不需要搜索。
而python的文档是chm的，因为chm支持搜索，所以也还凑合着可以用
---------------------
我可没有从这段话中看出来“你的意思是说打包过的chm要比html用起来方便。”
也许是我们两个人之中，有一个人的语文不及格？

[ 本帖最后由 flw 于 2006-6-15 10:37 编辑 ]

jkit

原帖由 jhbmail 于 2006-6-15 02:26 发表
namespace其实是一种比java的package更好的机制，名称空间其实就该和实际的物理位置无关。直接扔在lib的根目录也没有关系，你只要知道namespace就行。

你觉得java的package就和实际的物理位置有关了？有关的只是相对位置！
我的意思是说如果python的模块不是直接放在lib根目录下，而是根据功能分类放在不同的package下面这样会更井然有序。


我只是说了说python中个人觉得不方便的地方，为什么有些人就是“容不得半点沙子”呢？
我还觉得java如果能吸收python中一些方便的地方会更好，例如支持命令行输入语句执行等。

jkit

原帖由 flw 于 2006-6-15 10:31 发表
我可没有从这段话中看出来“你的意思是说打包过的chm要比html用起来方便。”
也许是我们两个人之中，有一个人的语文不及格？

严重同意！

jkit

纯html文件的javadoc我觉得就已经很好用了，因为它层次分明，很容易找到想要的文档，根本就不需要搜索。
解释下吧
前句说的是“纯html文件的javadoc”，“纯html文件”是用来修饰“javadoc”的，主要对象是“javadoc”，所以后句的“它”指的是“javadoc”，而不是“纯html文件”。
如果还不能理解，那我稍微改一下吧
纯html文件的javadoc我觉得就已经很好用了，因为javadoc层次分明，很容易找到想要的文档，根本就不需要搜索。

[ 本帖最后由 jkit 于 2006-6-15 10:49 编辑 ]

jkit

搞了半天我才明白，你以为我说的是
“因为纯html文件层次分明，很容易找到想要的文档，根本就不需要搜索。”
所以才有后面的跟贴说Python也有html格式的文档云云。
哎呀，真是，看来我表达能力还不够，当时怎么就没注意到会引起误解呢。

jkit

原帖由 flw 于 2006-6-15 10:27 发表
农村有句话：白吃的枣儿还嫌核大，这话不是在教训你，
而是说，Java 有那么雄厚的资金做支持，假如连个文档都写得不如 python 好的话，那 Sun 的那帮工程师还不如去吃屎。

既然你的意思也很清楚，javadoc要比Python的好，为什么还非要争得个什么似的。
我也不过是说一下自己的感觉，也没有因为这些就说python不好，何况，难道因为是开源的就不许别人说了？ 就算是Python的作者也会虚心接受别人的评价，又不是刻意诋毁，至于么！

jhbmail

你觉得java的package就和实际的物理位置有关了？有关的只是相对位置！
我的意思是说如果python的模块不是直接放在lib根目录下，而是根据功能分类放在不同的package下面这样会更井然有序。

---------------------------------------------------------------------------------
    呵呵，相对位置其实也是实际的物理位置啊，只是不是绝对的物理位置而已。我个人是觉得namespace作为一个逻辑抽象层，的确应该和具体（呵呵，是相对的具体位置哦）的文件位置无关。而java中将两者绑定起来，我觉得是不合适的。事实上，在c#中就抛弃了这种方式，我想不是没有原因的吧？
   将文件根据功能分类放在不同的package下面是一个很好的组织代码的方法。不过可能是我习惯使用IDE了吧，我很赞成《c++的发展和演化》中的观点：不将程序看作源文件和文本的集合，而看成类型的集合（记不清楚原文了，大意吧）。这是需要工具来支持的，而现有的工具正好可以让我们忽略掉底层源文件的组织形式，而工作在更高的namespace的抽象层次上。

   不断的寻求更高的抽象，这是计算机科学进步的方向吧。为什么这么多人喜欢python？我想正是因为它提供了对计算机更高层次的抽象的原因吧。

[ 本帖最后由 jhbmail 于 2006-6-15 18:59 编辑 ]

jhbmail

顺便说一下，在软件过程上我是赞成快速迭代的，设计和开发不应划分为两个截然不同的阶段。以前读《敏捷建模》中论述的建模和写代码的平衡问题给我的印象很深，设计是很重要的，但具体到实现代码中函数参数和返回值，我觉得就有点过了。
   当然，仅仅是我觉得。大家的开发习惯不同，这个度也该有所不同吧。

jkit

原帖由 jhbmail 于 2006-6-15 18:33 发表
   呵呵，相对位置其实也是实际的物理位置啊，只是不是绝对的物理位置而已。我个人是觉得namespace作为一个逻辑抽象层，的确应该和具体（呵呵，是相对的具体位置哦）的文件位置无关。而java中将两者绑定起来，我觉得是不合适的。事实上，在c#中就抛弃了这种方式，我想不是没有原因的吧？
   将文件根据功能分类放在不同的package下面是一个很好的组织代码的方法。不过可能是我习惯使用IDE了吧，我很赞成《c++的发展和演化》中的观点：不将程序看作源文件和文本的集合，而看成类型的集合（记不清楚原文了，大意吧）。这是需要工具来支持的，而现有的工具正好可以让我们忽略掉底层源文件的组织形式，而工作在更高的namespace的抽象层次上。

   不断的寻求更高的抽象，这是计算机科学进步的方向吧。为什么这么多人喜欢python？我想正是因为它提供了对计算机更高层次的抽象的原因吧。
------------------ ...

请你在胡说八道的之前先看看python的site-packages。

莫愁

原帖由 jkit 于 2006-6-16 15:37 发表

请你在胡说八道的之前先看看python的site-packages。

你这人怎么这么没礼貌啊？