请先理解:
http://wiki.woodpecker.org.cn/moin/ObpLovelyPyEditorRule

2008/9/1 黄毅 <yi.codeplayer at gmail.com>:
> 首先框架篇里面我看到每个框架只是几句简单的介绍，不知道是限于篇幅只写这些呢？还是没写玩？
是没有完成，清风一直和Liz 在前几章PCS中挣扎,,,,

> 我感觉就这几句话对读者用处不大吧，可否多放几句代码呢?比如写一个超简单的wiki，每个框架展示下基本的配置，输入一个简单页面，处理一个基本的form。应该用不了多少篇幅。

非常好哪！各个框架的 一刻钟入门的教材都可以拿来参考的,,,

> 而且是不是需要展示这么多框架呢？个人建议先介绍django
> （人气最旺，最容易上手，自动的admin灰常能够吸引眼球），其次再介绍个轻量级的（CherryPy 、Karrigell
> 、Web.py、web2py），展示pythonic的web程序。

PCS 的章节，不是顺序来读的，是作为前述故事书的各个知识点的补充，或是作为MINI手册来查阅的,,,

> 我觉得最好是用代码着重展示两到三个框架，其他的就几句话带过吧。
>
> 其次关于模块篇，不知道选择标准是什么，我觉得这几个模块选择不太好。
> 1. ConfigParser 和 dict2ini 提供是几乎相同的功能。
出现在实例故事中的时机和目的不同

> 2.thread 和 threading 也不应该分在两节。
理由同上，不过，的确可以合并

> 3. 本书针对的小白读者是不是不太会用到 epydoc 这么高端的功能？（话说俺一直到现在都没用过这玩意）
这是必须的，这是俺整本书，唯一比较深入的部分,,,
而且这根本不是什么高端的技术，而是最最基础和简便的开发好习惯！一定一定一定要推广！！！


> 我建议选一些在"主流语言"不太方便的甚至是没有见过的，而在python里面特别方便的东西在这里介绍：urllib2.urlopen
> (在我的忽悠经历中，有好几个人就拜倒在这个功能下了，可以和chardet 一起介绍)
PCS 的设立不是常用模块，而是对实例故事涉及技术的增补，所以，没有在故事中使用／开发的模块不进行描述，，，

> ，doctest（当然这个似乎也稍微高端一点，不过至少用起来还很方便，而且对于被java、c++这些语言的 unittest
> 折磨过的人绝对是有很强的杀伤力）
> 4.和命令行程序相关的几个东西：cmd、shutils、fnmatch等，正好可以凑在一起写一个有点实际用处的命令行程序。
这就是 CDays 中的 cdc 工具哪,,,,
>
> 最后，关于整本书、每个章节的篇幅有没有什么规定了没？
再次推荐 编辑约定:
http://wiki.woodpecker.org.cn/moin/ObpLovelyPyEditorRule

请根据现有内容结合约定，理解图书的整体 ;)

然后快乐的加入有兴趣的章节进行增补吧！

>
>
> --
> http://codeplayer.blogspot.com/
>



-- 

http://zoomquiet.org'''
过程改进乃是催生可促生靠谱的人的组织!
PE keeps evolving organizations which promoting people be good!'''