小明读书Python,小明读书第一天读了三分之一

　　你真的了解python吗？2013年8月2日

　　http://www.dongwm.com/archives/ni-zhen-de-hui-pythonma/

　　前言我的这个博客一直是分享一些技术和展示代码的地方。我从未写过个人生活或情感八卦。当然，我从来没有谈过我对任何事物的好恶。很多人喜欢喷XX语言，谈论XX和YY的优劣，甚至拼凑出一本不知所云的书……好吧，我不认为我用了10多年的语言，或者学了5、6年的技术。很抱歉的说我懂(天才除外)。我也不认为我有资格讨论任何事情。也许我有自己的看法，但我用怀疑的眼光看着自己，生怕自己理解错了。以下纯属个人评论。也许我没有指明方式，但我只是想提醒你…

　　用了2年python，欣慰的是python被越来越多的人接受，甚至是前端工程师……但是有点不好的街头感：和人打招呼不说python都觉得不好意思。但是你真的了解Python吗？

　　你懂不懂python真的不重要。python太好学了。如果你懂其他语言，可能翻一本书，一周就能写出高端python程序。由于web框架的流行，你甚至可以运行一个网站应用程序。你也可以认识我。你有什么竞争力？

　　你知道如何使用python吗？我什么时候需要使用OOP？什么时候使用类装饰器？你用过元类吗？什么时候使用静态方法，什么时候使用类方法？你知道哪些管理属性？call、init、_ _ new _ _都是什么时候触发的？__getattr__和__getattribute__ application有什么区别？你知道标准库中有多少模块？你可以在需要的时候知道这个函数其实已经在标准库中实现了。什么时候使用回调？何时使用信号？如果你认识姜戈，你知道姜戈的信号是什么吗？你知道orm吗？Asyncore，contextlib，functools，collections，heapq，itertools，SocketServer，weakref，operator(就算你知道三个)，这些你知道几个？python的多态性是什么？在什么场景下可以尝试python的设计模式中的XX(即使你能想到两个场景)？什么时候可以用Mixin？什么时候可以使用python闭包？你用过yield吗？生成器和迭代器的区别和应用场景是什么？python的函数式编程可以用什么？__future__模块中使用了哪些定义？我思考了以上16个我认为体现python的东西。如果你不能有效回答以上1/4，好吧，别跟我说你懂python。脚踏实地。你还有很长的路要走。如果你回答不到一半以上，我提醒你——你只是个行业新手(这是我的观点)。

　　如果我是一个带新人学习git的向导…嗯…呵呵，如果新人不熟悉python，python_koans是一个不错的入门选择。首先，严格的代码规范，加上团队的文化和风格。我会给一个任务，比如一周之内写一个多线程socket命令行聊天程序，支持加群，加好友，群聊，发文件等功能。这要看新人的能力，然后教他一些项目的棘手工作。注意这是生产环境，他会在完成任务的过程中熟悉我们的在线/代码评审/代码风格等东西。希望整个团队贡献一个基础的公共库，包括一些常用的功能，然后新人先学习这些东西，以后就不用浪费时间造轮子了，公共库可以修改完善。这个公共库可以在新服务器部署时直接用pypi或ubuntuPPA安装。什么是好？如果你的代码没有被pep8检查过，你就是无敌的。最坏的情况下，你必须使用autopep8格式化糟糕的代码，对吗？如果你想对你的代码质量有要求，我强烈建议你知道pythonic是什么：

　　[an-introduction-to-the-Zen-of-python作者Doug Hellmann](http://www . slide share . net/[doughellmann/an-introduction-to-the-Zen-of-python)Be-python代码很容易理解，但堆和代码很难理解，但需要精确的权衡。我觉得有很多人追求代码。看到项目中有大量没有复用的函数，看似相似的方法甚至是方法的名字……我是看不出丑陋或者华而不实代码的人，但是有一个问题。我打包的代码不直观，难以理解.原始代码似乎非常容易理解。每个人都有自己的理解。就像我团队里有人说django代码太难理解，因为他们有django项目团队的文化.如此令人欣慰的评论，芹菜代码写得不好.但我不这么认为。我还在读芹菜代码，我承认它有作者的命名或实现风格，但我学到了很多。

　　通过阅读源码，比如django，requests，flask。我会去找很多别人的用法总结，去思考别人为什么这样用。比如项目代码的目录结构，一些问题的解决方式，pep8中没有提到的一些规范。例如，一些实用的代码样式，例如：

　　我们的代码引用其他类似的模块：

　　从测试导入long _ long _ long _ test1从测试导入long _ long _ test2表单测试导入long _ long _ test3省略了20多行，很烦吧？有一种风格

　　从测试导入long _ long _ long _ test1，\ long _ long _ test2，\ long _ long _ test3，说一个窍门：在我不知道用什么的时候，看看怎么用NB项目。django和requests就是这种风格。

　　测试导入(long _ long _ long _ test1，long _ long _ test2，long _ long _ test3)进展如何？不是闭门造车.先去看看别人是怎么用的。

　　例如，我曾经像这样拼接一个文件路径：

　　{0}/{1}.事实上，人们有：

　　Os.path.join(dir，filename)惭愧。然后花了半个小时把我以前做这个的地方都换了。

　　这是我提出的重要观点：如果你知道什么是对的，你就应该改变它。

　　我对这个话题的回答：我喜欢难懂但精炼的代码。境界就是看得懂就能写。如果连这段代码都看不懂，就看不到开源项目的做法。你永远是个码农。你会一直堆积垃圾代码。你会增加未来接班人的维护成本。

　　如何提高python的可读性和质量？以下是我的想法。

　　首先给函数/类/方法起个通俗易懂的名字(这一点我失败了，英语太差了…要学好英语要加一个吗？)类似的操作出现三次时，不要继续堆代码，而是抽象出来。我倾向于写FIXME，TODO，写注释说明文件/函数的用途，注释不容易理解的代码，说明输入输出是什么(如果不是为了修改维护你的没人管你的算法有多NB)。请不要让别人需要仔细研究你的代码才能理解它的意思.我写代码压力很大，因为我不想被我带的人骂。不要卖弄技巧，请不要乱用函数式编程/闭包。我在意的是性能和简单粗暴的实现功能。用标准库来实现。如果不知道这个功能，先谷歌一下。在github上阅读更多关于著名项目的信息。

　　我们是打包开源项目还是直接修改开源代码自己用？其实我是这样描述的。例如，由于历史原因，一个项目是早期版本。但是，它与其他新版本组件以及我们业务的特殊需求存在兼容性问题。我看了源代码，发现需要做几处改动。变更之后，我需要自己维护这个项目。对于新部署的环境甚至其他版本，我仍然需要这种改变。还有一种声音说“你不能修改XX源代码。”你需要在上面封装一些新的东西，也就是说，不要直接调用XX，你需要在我自己的项目YY中封装XX，然后我们调用YY。

　　我觉得自行部署这个东西是一个可行的方案。首先，这个改装不是补丁，也不是主流改装。只能算是我们业务的二次开发，封装只是一种掩饰。这让我想起一个问题：为什么中国好的开源项目很少？中国人不缺好点子？是因为中国人觉得这个东西不行，因为觉得别人取得的东西很牛逼，改了就有问题……其实这就是自卑.首先，代码会有bug。tornado/flask/requests不是还在开发解决问题吗？只是你一直没注意到bug而已。我认为如果你理解一个开源项目的代码，你可以修改它.没什么可担心的.我是说角度。我想大家都学过一门语言，看过某个项目的源代码。只要你有发现和思考的勇气和怀疑的心，那么你就可以贡献你的代码，做你的二次开发。

　　与本文相关：如果你没有这样做过，你怎么能说你懂python呢？

　　我不认同“做好就行”的论调。对你个人来说，明年的今天你要做的事情和现在是一样的。不同的是你大了一岁。如果你完成工作是为了什么，你的代码其实就是在线运行的代码，而且会用很长时间。你的一些随机代码在很长一段时间后将很难改变.我也不同意你写的程序一旦开始就要承受千万级。

　　董伟明发表于2013年8月2日Python。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。