按 ‘ 编程 ’ 标签归档
鸟类的学名俗名、中文英文互查，我比较相信AVIBASE，但它（从墙内）访问起来太慢，我屏蔽了里面的各色敏感站点都没用。一发狠，写了个网页代我访问，再把数据丢过来。为避免滥用AVIBASE，这个网页里有意加了一些延迟，但还是比直接访问快多了。
调试时遇到的小惊喜：抓取网页内容空白，即使我把phpQuery里file_get_contents扩写为cURL的也没用。最后找到的原因是，AVIBASE拒绝爬虫，需要自称是个浏览器，表现在程序里，就是在cURL初始化时加这么一句：
curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 Chrome/77.0.3865.90');
这是一篇迟到的总结，其实今年2月就已经赢了的。写这个总结是为了详解打僵尸程序的进化过程，帮大家看懂它的战术和走位。
众所周知，渣浪微博的僵尸化很严重，并且渣浪无计可施。很多人以为“微博反垃圾”有用（起初我也这么以为），但微博反垃圾这样解释自己的功能：
也就是说，当某用户被举报封号时，渣浪并不会及时清理它和正常用户的关注/被粉关系，直到该用户手动修正粉丝为止（并且只修好他自己的）。其实这是把流程缺失的责任转嫁到用户身上。并且，从这个解释来看，让绝大多数人头疼的僵尸粉，在渣浪眼里是正常用户：不说话当然不会被举报封号啦。
第一次使用微博反垃圾的，会很欣喜，因为立竿见影，一下子粉丝数就降下来了。那是当然，堆积N年的陈年老尸，被火化时肯定狼烟滚滚。但再使用时，它只能帮着清掉从上次大扫除以来积累的垃圾，效果就会令人失望了。
所以我决定自己搞定这件事。从去年11月开始，用Python语言写了个程序，中间随着战斗局势变化，修改几回。大约到了12月中，程序功能基本上就是今天的样子了。
我把僵尸粉分为这样三种：
对这三种僵尸的识别处理，是推进程序的主要动力。下面细说程序的演化过程。
首先说说起始状态。一个被僵尸粉占据的帐户，其粉丝列表大约是这样的结构：
图中，红色代表僵尸，蓝色代表正常粉丝，灰色代表250页之后、被渣浪隐藏的粉丝列表（可以想象，其中的僵尸依然是多数）。数字是粉丝列表的页数。渣浪的规则：即使看自己的粉丝列表，也只能看至多250页，每页20个（即最多5000个）。假如看别人的，则最多只能看5页（100个）。
我们期待的理想健康状态，当然是下图这样的，红色泡沫被挤空，蓝色真粉致密地聚集在一起：
知道了自己在哪儿，目标在何方，就可以着手制订路线，准备工具。
最初考虑的是渣浪自己的微博API——它自己家的东西嘛，用起来肯定最趁手。但仔细阅读其功能后就会发现，根本没有删除粉丝的接口（曾经有，后来撤了，让人高度怀疑，僵尸粉都是渣浪自己喂养释放的）。
那就只能自备工具了，我使用早有成熟功能库的Python + Selenium。
和网络相关的编程，最简单直接的操作是“访问链接”，于是，可行性预研从这个办法入手。经过调研发现，“访问1个链接就能删除1个粉丝”的功能，在手机浏览器彩版微博（不是手机客户端）可以实现，但彩版微博最多只给看1000个粉丝。
所以程序最初分为两节：第一节从网页版微博抓取粉丝列表（至多5000个），分析僵尸后写进数据库。第二节读取数据库，把标记为僵尸的，通过访问彩版微博删除。删除之后，前250页留下的空位，会从原本隐藏的地方（上面图中所示灰区）抽调名额填补，这样就又可以循环以上过程，轮转不已。
这个方法确实有用，帮着我删除了最初一两千个。还让我发现，刷页不能过快，否则会被微博拒访几分钟。最初的删除速度，可以点这里了解，但此视频的续集就是几分钟的空白页面，飞速删除所节省的时间全赔进去了。从此，大约两秒1个的“稳健”速度一直保持到最新版。认为这个程序不够快的用户，读到这里应该能理解了。
接下来，我开始对程序的分节运行感到不爽。眼前分明一群僵尸，却要等几十分钟后才能看到它们被删除。更重要的是，抓取和删除间隔久远，谁冤枉了，谁漏网了，根本对不上号。所以我开始做即见即删的版本，看到僵尸就立刻操纵鼠标去打开菜单，点删除按钮，不再攒到一起秋后问斩了。
拉菜单点按钮敲回车的操作当然要比访问链接复杂得多，幸好Python + Selenium的功能还挺齐全，很快就搞定了改写工作。
最初程序分两节运行时，只要能把粉丝列表逐页看完就行， 正着看倒着看并不重要 。但到了即见即删的阶段，访问顺序就变得很重要。即见即删的第一版继承了正向浏览的基础，那时的工作方法是：浏览第1页，删除本页上的僵尸，腾出空位来了，刷新本页，把原在第2页的粉丝填上来几个，再删再刷，直到本页全是活粉，再挪到第2页如法炮制。
说真的，假如不考虑效率的话，这个操作过程比现在的版本还花样繁多，令人沉迷，每次运行时我都能盯着看很久。也正是因为看很久，看出问题了：20个位置，前19个都坐满了活粉，只剩1个空位时，程序还不屈不挠地刷呀删呀，每刷只能删1个，太弱智了。
于是做了个改写，每次从250页逆行到第1页，刷完删完不停留，继续上行。这样每次看到的都是新面孔。当有僵尸从第1页正门持续涌入时，逆流而上更是所见常新。程序朴实了，却变得高效。
读到这里，用户应该明白为何程序总是从后往前扫了。至于每次开始程序总是先看第1页，那是因为要读取最大页码，好知道从哪里开始做起。
逆向即见即删版做完后，程序夜以继日地干活，很快把粉丝删成了这样的分布：
这是一个典型的删粉进度。大蓝块是沙里淘金浓缩成的活粉大军，它左边是正门涌入的僵尸粉，右边是有待处理的旧僵尸。
这时我开始担心两件事：一是假如程序还这么傻不拉几地从250扫到1，那么它的大部分时间会浪费在活粉大军上，并且越来越耗时。二是最终删成下图这样时，前250页挤满了活粉，按关注时间排序的新僵尸只从左边进，旧僵尸从右边冒不出来，程序必然熄火。
第二个问题无计可施（也就是说，真粉极多的大用户，不要指望这个程序带来太大的改观），先解决第一个。我在程序里加了几段代码，让它一旦撞到大蓝块，就指数级速降，尽快跳到粉丝列表的头3页去工作。每清完头3页，就相当于把大蓝块往左拽一拽，从右边抽出更多的粉丝列表来。反正在活粉大军前面干活也是干，后面干活也是干，都没有浪费宝贵时间。
读到这里的用户应该能明白，为何250、249之后，突然就skipping active fans，快速地跑到第3页去了。也会有用户问，可有时程序还是继续老实巴交地248、247、246呀。那是因为我担心有些“活粉”会退化成僵尸，所以安排了5%的概率，让程序重新审视活粉大军，看看有没有蜕变了的。
说到活粉的退化，就要谈谈僵尸的定义了。最原始的定义当然是发博少，但怎么才叫少？注册10年的用户发10帖可以称作少，而来微博刚俩月的，发10博就还算可以了，所以发博量要用注册时间来衡量。准确的注册时间并未体现在粉丝列表里，不过从此人ID上可以看出来。通过采集大量的数据，我得到了这些信息：
这些信息给了我一个经验公式。从粉丝列表读到他们的ID时，我大致可以知道他们何时来的微博，再按照每月一博的标准（很宽容了）来衡量，低于这个阈值的，就判为僵尸删除掉。
所以，随着时间的流逝，曾经的活粉退化为僵尸是很有可能的。有人会说这是误判，但我认为，一个人如果喜欢潜水——后面会提到，一些僵尸都比他活跃——那么他对被粉的博主只是日常“视奸”，并未传播博主的信息，留他何用呢？
再说打榜僵尸。这些帐户的存在通常和某明星或某活动有关，是买来的帐户。在演唱会、见面会开始之前，异常活跃。并且抱团互粉，同进同退。单单从粉丝量、关注量、发博量上来看，都不易判为僵尸。下图是一坨样本。
严格来说，他们并非僵尸，结群出现到处留言点赞，无非是想吸引你点开他们的页面，看看他们爱豆的最新动态。但他们是为爱豆来的，与我无关，留他们干嘛呢？
单从数字上识别这一类的僵尸很不容易，活动进行期间更是不可能，结群出现时容易感知其命名规律，但这种规律经不起时间考验，不能放到打算长期运行的程序里。幸好活动一过，他们就会闭嘴。于是，我在程序里做了一个新动作：翻检每个粉丝的主页，如果他们持续静默3个月，就判为僵尸。右图里的这些ID，在新规则出台后很快被删了个一干二净。
翻检主页的动作比较耗时，所以程序只在闲时才做。当它扫完一页，没看到经典僵尸时，就会认为咖啡时间到，从数据库里挑选10个最近没看过的ID，一个个翻阅其主页。“微博会员升级啦”、“生日快乐”、“抢了个大红包”这一类的自动信息不计入此人发帖。
读到这里的用户，应该能明白为何程序忽然不刷粉丝列表，而是去浏览用户主页了。
羽翼初丰的程序刚刚开开心心地运行了两三天，我遭遇了来自渣浪的第一次打击：它只给我看两页粉了！这种情况相当于提前进入了被活粉憋死的熄火状态（想象一下上面熄火图中的250改为2）。很有可能是前期可行性测试时，对微博访问过频，被渣浪的系统安全机器人留意到了。
挑战也是机遇嘛，逼迫我提前考虑如何在熄火状态下持续工作了。最终发现，“按最近联系人排序”的话，互动粉丝列表（最多50页）的后半段还能看到许多僵尸粉（并未互动过）。这个列表不会实时更新，删除僵尸后，第二天大约同一时间才会填充新的。不过，每天还能删大约500个，聊胜于无呀。
读到这里的用户应该能明白，为何程序一上来就先从第50页扫描互动粉丝列表了，而且一旦扫完，8小时内不会再碰。昨天有个用户哭着对我说，为什么要删互动粉丝啊？他们都是活粉真粉啊！我拿到她的活粉样本一看，2010年注册的，发帖24，僵尸都更活泼些……
还有潜水员一听我要打僵尸，马上跑来评论：“真粉报到！”“我是活的！”他们假如不吭气还没事，一说话，第二天就上了互动粉丝列表，被程序看到了，发博数本身就可疑，再翻翻主页三个月没说话，就手起刀落了。
同样，我不把这些叫冤杀，如果不想被判为僵尸粉，应该活出自己的精彩来，经营好自己的地盘，不要只在别人家做客。
对于活粉很多的大用户——哪怕僵尸也很多——相信活粉还是能挤满50页（1000个座位）的，这个放僵尸的门缝可能并不存在。
熄火运作了将近1个月，渣浪忽然又开放了250页列表（后来这类事情又发生过两次），迎来了重新开工后的大高峰。
从此僵尸粉一溃千里，今年2月，最终删到了5000以下（250页以内），所有粉丝都移出灰区。终于有把握说，我赢得了这场打僵尸的战役。
此后又有几个次要更新，包括对“真是活人”的提前赦免，以及对自语僵尸的判断（逻辑尚在试运行中），都是细枝末节的事了。
最近有些饱受僵尸困扰的用户来下载使用这个程序，有一些给我的反馈里，提出了很好的建议，打开了新的思路。例如，自语僵尸，我这里没几个，而在别人那里则是主要问题。也有抱怨声，比如程序有点慢，为什么要翻看主页，为什么冤杀活粉，等等。我想说，僵尸没有一定之规，几套判断逻辑互相辅助制衡，共同把僵尸逼上绝路，推敲了大半年。随着局势变化，有些看似漫不经心的流程会渐渐凸显其作用。都是我亲自趟过的坑，好不容易填平了的，请不要再把我拽回坑里去了。
在删除僵尸粉的自动化方面，做了一点微小的工作，免费分享一下。
准备过程有点复杂，既然是免费分享，服务支持是谈不上了，我只介绍大体如何设置，能看懂的应该就克服各种困难了，看不明白的也不能多解释了……
对于首次使用、中途也无意外的用户来说，不疾不徐走完上述设置步骤大约需要15分钟。如果你的粉丝总数小于200，那么手工删除更加省时稳妥。
其它信息：
帮朋友代管一个问答站点。这个站点常常被发垃圾广告的盯上，而且使用注册发帖机器人，潮水般地往上冲。最近一次大规模攻击出现在10月15日晚上到16日早晨，总共产生了43000多条垃圾。
因为只是代管，所以我并不能接触到后台代码和数据库，只能使用网页管理界面来清理垃圾。而这些网页界面又有点残疾，例如，删除垃圾问题时，虽然提供了多选勾框，却只能删除顶头一个。
汇总一下，手边能用的抵抗工具有：
好在我还是个程序员，虽然并不穿格子装。当天下午，我用JavaScript写了个网页，把垃圾用户/问题的编号范围输入之后，点一下“清理用户”，它就会循环往复地按照原站点期望的格式生成form，并提交删除。按照每秒清理10个用户的速度，很快就干干净净了。
这个清理工具有点小花样：提交删除表格时，会在新窗口打开（否则退不回来，就没法循环执行），打开的新窗又要在5秒钟后关闭（否则任务一多，浏览器的窗口就密密麻麻了）。这样，浏览器不停地弹出新窗又关掉，忙得不亦乐乎的样子，煞是好看。
写好这个清理工具之后，把它往自己的网站上一丢，就可以放心地出去玩了。即使问答站点再遭攻击，我也可以从手机上远程清理了。执行清理代码的权限依赖于事先在问答站点上成功登录，所以也不担心链接泄露被网络爬虫乱点按钮。
接下来我又想：事后发现并清理，终究显得有点被动。当我忙着做图写东西时，还得随时盯着站点，就太分心了。JavaScript在读取外域网页时功能有限，所以我用PHP写了个新版本，能代刷网页，发现出事时，能自己清理。不过，本质上，这个工具就和注册机器人一样了，这大概就是传说中的“终于活成了自己讨厌的人的样子”。
自动防御工事的逻辑是：
刚刚写好新工具，一个小机器人就吹着喇叭发动了祭旗式的攻击（上图的UNDER ATTACK指的就是它），攻击从当天傍晚6点持续到次日凌晨零点。刚才说过，每次检测出批量攻击时，程序会先关闭用户注册半小时，然后打开，半分钟后再杀回来重新看一眼。对面这个小机器人在这每次间隔半小时的半分钟缝隙里，急急忙忙地创建垃圾用户，几个小时过去，它用掉了将近一百个帐户编号，也算是相当执着了。
今天早晨出了个巧之又巧的小意外。在网页刚刚启动，进行30秒热身刷新时，放在本站的服务器突然跳表，时间戳从23:01:32跳回23:00:20，呛死了我的防御工事。
它的判断逻辑是“假如新注册的用户数乘以某比率，大于刚才流逝的秒数，则判断是注册机器人攻击。”而这里，虽然新注册用户为零，但“刚才流逝的秒数”是个负值……万幸的是，我从做JavaScript版时，就设了个保险杠，此杠以内的老用户无论如何不能碰。所以虽然代码走进了“删除某些用户”的那一块，却立刻被驳回了。
感谢这个服务器提供的意外test case，这部分代码已加固，不会再被弄死了。
后记：晚上在本站服务器上把玩这个程序时，跳表现象又出现了。不禁大感兴趣，细细研究一下这个现象的来源。它发作得如此频繁，使我无法相信有个系统管理员坐在那里没事调时钟。更像是有多台负载均衡服务器，它们的时钟不一致。
写了个小网页，每5秒输出一次系统时间，在完美世界里，应该获得一条单调上升的直线。然而我实际得到的，是剧烈颠簸的数据。使用Excel画出来就更加一目了然，共有三条直线，说明至少有三台负载均衡，其中两台差异不那么大，而第三台慢了许多。如果拿中间一条线做参照的话，最上面的时钟快了23秒，最下面的则慢了108秒。
话说，这道题，十几年前，玩论坛的时代，就出现在网上了：
三道门，一道门后面有车，另外两道门，后面都是羊。
有个节目主持人，他知道车在那道门后。
他请你选一道门，但不立即打开。
他在剩下的两道门里，打开一道，放出一只羊给你看。
现在台上还剩两道门关着，一道是你选的，一道是谁也没碰过的。
主持人说：现在你有个机会，可以改变主意，挑另一道门。
不管你换还是不换，你最终选中的那道门，后头的东西都归你。
你换不换？——假设价值观是车比羊好。
当时，论坛上吵成一片，有说该换的，有说不该换的。对于不换而中奖的概率，大家比较一致：1/3。而对于换而中奖的概率，基本上有三个说法：1/3、1/2、2/3。
论坛上贴题的那人说：“正确答案是应该换，中奖概率会从1/3提升到2/3。并且，此答案经过了智商排名极靠前的一位人士的认可。不过，还是有许多不愿盲信权威的年轻人，自己动手，用各种办法做实验，有大活人亲自做的，有用计算机模拟的，而结果一致确认：该换，中奖概率确实提升到了2/3。另外，虽然实验结果如此，有相当多的亲手做实验的人依然坚持（理论上）不该换。”
时至今日，这道题提到人口稠密的社交媒体上来，依然能够引起争论。
为了让读者老爷们怀着轻松的心情观看余下的内容，我提前把答案确认一下：
应该换。
我不是从一道门换到另一道门，
而是从一道门换到另外两道门。
“换并且选到车”的概率 = “第一次没选到车”的概率
三道门的迷惑性较大，读者可以极端化一下：如果是一亿道门，你挑一扇（选中车的概率很悲观），然后主持人把许许多多门打开，放出来满坑满谷的羊，最后只留下一道门，你换不换？
或者再换一个思路：主持人挑你和另外一个现场观众上来，让你选一道门，让那位观众选两道门，然后问你，愿不愿意拿你的一道门换那位观众的两道门？
“开门放羊”只是个迷惑动作，当门的总数大于2时，挑剩下的门里，一定能放出至少一只羊。所以它没有增加任何信息，也没有改变概率分布，这一步骤和事后开奖并无不同。
用概率论的运算过程则是：
如果你看到这里还是觉得数学上不该换，那就可以关掉页面了。接下来并没有理论上的新内容，而且因为要用程序表达，技术上会比较烧脑。我不想让你同时背两个包袱走路，会芯片过热的。
虽然这道题没有数学理论难度，我还是想拿它做个编程的例子。原因是，我发现用计算机的思维，可以洞穿这道题的本质。做完实验依然坚持不该换的人里面，一定没有用计算机模拟的。
我的第一版程序很简单（手机读者可用手指左右拖动代码区）：
import random
def lottery(n, change): # n是门的个数，change设置“换还是不换”
car = random.randint(0, n - 1) # 为车生成一个随机的门号
pick = random.randint(0, n - 1) # 我选择一个随机的门号
# 如果我未选中车但愿意换，或者我选中了车并且不换
if (pick != car and change) or (pick == car and not change):
return True # 我都会中奖
else: # 否则
return False # 就不会
repeat = 100 # 重复做此实验100次
win = 0 # “中奖”计数器置零
for i in range(repeat):
if lottery(3, True): # 每次都选择“换”
win += 1 # 如果中奖，计数器加一
# 打印中奖百分比
print("%.2f%%" % (win / repeat * 100))
结果如何呢？运行三遍：
=============== RESTART: cargoat.py =============== 68.00% >>> =============== RESTART: cargoat.py =============== 71.00% >>> =============== RESTART: cargoat.py =============== 68.00% >>>
100次实验，如果选择“换”，中奖次数确实在2/3左右。当然我们也得反过来做一下，把lottery函数的第二个参数设为False：
repeat = 100 # 重复做此实验100次
win = 0 # “中奖”计数器置零
for i in range(repeat):
if lottery(3, False): # 每次都选择“不换”
win += 1 # 如果中奖，计数器加一
# 打印中奖百分比
print("%.2f%%" % (win / repeat * 100))
运行三遍，选择“不换”的中奖概率确实较低：
=============== RESTART: cargoat.py =============== 34.00% >>> =============== RESTART: cargoat.py =============== 34.00% >>> =============== RESTART: cargoat.py =============== 27.00% >>>
还可以发现，实验的重复次数（repeat的值）越高，中奖概率越是稳定在2/3上，下面是repeat = 100000的三遍运行结果：
=============== RESTART: cargoat.py =============== 66.55% >>> =============== RESTART: cargoat.py =============== 66.81% >>> =============== RESTART: cargoat.py =============== 66.70% >>>
在这个程序里，原本热热闹闹的挑门、开门放羊、问你换不换的那些动作，一下子被简化成了“你第一次猜中的概率有多大”的问题。我刚才说：“做完实验依然坚持不该换的人里面，一定没有用计算机模拟的。”是因为写程序前，我先假装认为不该换，而写下lottery函数的前两行时，就找到了事情本质的描述方式（上面的粗大字体）。
然而，读者可能认为，我并没有精确地按照剧本来写，所以运算结果不可信。为此，我必须按照剧本写一遍程序，像宋小宝吃面那样，辣根和蒜瓣这些步骤都不能省。说实在的，因为需要彻底改变思路，写新程序很累，但我还是勉力完成了：
猛击阅读全文
三年前往博客里添加了一个微博分享按钮，最近发现微博分享方式有WBML新版了，于是按照微博介绍的WBML界面重写了这段代码。
先贴代码。新版的添加微博分享按钮的方法：编辑正在使用的monochrome族主题（其它主题可能要微调）的header.php，做两个改动：
一、在<html>标签后增加wb命名空间：
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:wb="http://open.weibo.com/wb">
二、在</head>之前加入以下代码：
<script src="http://tjs.sjs.sinajs.cn/open/api/js/wb.js" type="text/javascript" charset="utf-8"></script>
<script type="text/javascript">
jQuery(function(){
// window.setTimeout(function() { // Make it asynchronous if using the iframe mode.
jQuery('div.post').each(function() {
var url = jQuery(this).find('h2.post_title > a').first().attr('href');
if (typeof(url) == 'undefined') {
url = location.href;
}
var titlestr = jQuery(this).find('.post_title').text() + ': ' + jQuery(this).find('p').not('.wp-caption-text').text();
titlestr = titlestr.replace(/\s\s+/g, ' ').substr(0, 110);
var buttonstr = '<div style="width:95%;text-align:right;margin-top:-40px;margin-bottom:40px;">';
var param = {
url:url,
type:'button',
addition:'number',
picture_search:'true',
title:titlestr,
ralateUid:'1691250947' // 关联用户的微博用户号码
};
var temp = [];
for(var p in param) {
temp.push(p + '="' + encodeURIComponent(param[p] || '') + '"');
}
buttonstr += '<wb:share-button ' + temp.join(' ') + '></wb:share-button>';
buttonstr += '</div>';
jQuery(this).find('div.post_content').first().after(buttonstr);
}); // jQuery.div.post.each
// }, 5000); // window.setTimeout
});
</script>
第一次重写后，IE不稳定地显示按钮、Firefox完全不行（IE竟然胜出，奇迹）。调试发现和一年前的一次优化有关。当时我把分享按钮的JS代码改为异步（橙色代码，页面加载完毕5秒后）运行，而此定时器似与WBML版按钮冲突。
之所以怀疑这个定时器，是因为观察了博客右边栏放置的静态代码“微博关注”按钮。我留意到它总能显示，并且当整个页面加载完毕、网页闲下来时才开始运作。猜想渣浪也发现这些按钮很耗时，于是也在按钮里内置定时器，把我这些外层的定时器顶得不干活了。
另注：渣浪程序员把“关联用户”的设置参数命名为ralateUid，嗯，从上一版延续至今以后也一直会继续错下去的拼写，厚道地猜想这是为了防鹅防寨故意拼错的。另外，微博文档里说抓图选项是searchPic，而快捷设置页里则可以看到是picture_search。我测试之后得知，picture_search是有效参数。
以前的几个章节里，大家一定常见到print(…)、range(…)、max(…)之类的结构，它们是什么呢？
它们叫函数。不用管这个名字听起来多么奇怪，和数学上的函数、方程的概念多么不同，先接受这个名字，后面我会说这个名字的来历。
比如说，我们在《程序在干什么？》一节的最后一段举过一个求平方根的例子，后来在《初涉算法》一节讲解过它。就拿这个程序为例，如果现在我想求(根号2 + 根号3) x (根号5 – 根号7)，该怎么写程序？
当然我们可以把这个例子复制粘贴四遍，第一遍求根号2，第二遍求根号3，第三遍求根号5，第四遍求根号七，然后用这四个中间结果算出最后的值。
这个思路能干活，可就是直觉太傻太啰嗦。四段程序只有喂给它们的数字的差别，实在是太浪费了。所以人们想，可以引入数学上的函数y = f(x)概念，定义好这个函数的公式（f）之后，把参数（x）喂给它，让同一段代码对参数进行运算，运算结果放在y里，这样岂不节约？
好主意！我们现在把求平方根的算法定义成一个函数：
>>> def mysqrt(n):
high = max(1, n)
low = 0
while True:
result = (high + low) / 2
if abs(result * result - n) < n * 1E-8:
break
if result * result > n:
high = result
else:
low = result
return result
>>>
这段程序里最关键的是第一行，以关键字def引导的函数名mysqrt，其后以括号包围要传递给这个函数的参数n，最后是冒号表示：以下的缩进内容是用来定义这个函数的算法。
最后一行return result也很重要，见到return语句时，程序就会返回到使用函数的那个位置，在相应的mysqrt(x)的地方，放上本次运行得到的result值。这个值被称为返回值。
说得再多不如实际做一次：
猛击阅读全文
从前我用过的程序示例里面，使用的数据都是分离的、独立的。就是说，每个常量和变量，各有各的用途，没有“我们是一伙的”这样的共性。而在现实世界里，成群结队地出现的数据是大多数。例如一架飞机上的旅客，一个班级的学生，奥运会的参赛国。
我见过的所有编程语言都有数组（Array，List）的概念，用来存储具有共同属性的批量数据。在Python里，数组用一对中括号包围的一群数据来表示，数据之间用逗号隔开。例如：
>>> countries = ['China', 'USA', 'Germany', 'Canada', 'Japan'] >>> countries[0] 'China' >>> countries[3] 'Canada' >>> countries[4] 'Japan' >>>
在这里，countries就是一个数组，它有五个元素（Element），每个元素都是一个字符串表示的国名。引用这些元素的时候，我们使用一个整数，来指明它在数组里的位置，这个整数叫做下标（Index）。和大家的习惯稍有差异的是，在Python里，当我们说“数组的第一个元素”时，我们用的下标是0，第二个元素的下标是1，第三个元素的下标是2，依此类推。所以上面的程序范例里面，countries[0]打印出来的是第一个国名China，第五个国名使用的下标是4。
如果你觉得这个规则挺怪异的，想一想这个问题：进入一座楼房，爬到一楼需要爬几层楼梯？爬到五楼需要爬几层楼梯？然后你就释然了，因为对于计算机来说，数组就像楼层，一楼就是它的第一个元素，其它的楼层都是相对于一楼的偏移量。英式英语里，一楼叫做Ground Floor，二楼叫做First Floor，三楼叫做Second Floor，这就是计算机式的思维。
C/C++、Python、Perl、Java、PHP等语言里，第一个元素都是用下标0来表示。FORTRAN、BASIC、PASCAL等语言里，第一个元素是用下标1来表示。这两种表示方法都是合理的，照顾不同人群的思维习惯。
在刚才这个数组里，使用countries[5]会看到什么？
猛击阅读全文
一口气写了十几章，轻松一下。
读者老爷可能有点昏沉了，说，这么多章节了，怎么还没见到一个Windows程序呢？咱们就写一个。
在Python Shell里按Ctrl-N（或者点File菜单，选New Window），在弹出的编辑窗口里输入——或者拷贝-粘贴也行，反正今天是“轻松一下”：
import tkinter
root = tkinter.Tk()
root.geometry('240x180')
root.title('hello, world')
tkinter.Label(root, text = "hello, world").pack(fill="both", expand=1)
root.mainloop()
按Ctrl-S（或者点File菜单，选Save），随意起个名字，存好文件之后按F5。
怎么样，看到Windows版的hello, world了吧？虽然看起来十分傻，但既然能写hello, world，就能写别的，就能放按钮，就能画图表，就能放菜单，能写一切能想出来的东西。要紧的不在于界面是什么，而在于理解漂亮的外表背后发生的事情。况且，就连这个漂亮的外表本身，也是由灰头土脸的程序写成的。
其实咱们早已看到过循环了，只是当时并没有要求大家看明白。
循环，就是让程序反复执行同一段代码。利用计算机速度快，脾气好，不怕麻烦的优势（这几点，人类确实比不上），也省得人们把相似的任务反复书写几百遍。
有两种循环，一种是事先预知要循环多少次的，一种事先不知道。这两种循环，咱们在《程序在干什么？》一章里见过。那里头讲过三个例子，第一个例子是从1加到100，我们都知道要循环100次。第二个例子是九九乘法表，我们知道要重复做9行，每行做N列（N等于当前的行数）。第三个例子是猜平方根，这个就不能实现确实要循环多少次了，只隐约觉得精度好过亿分之一就可以结束。
预知循环次数、知道每次循环时要喂什么数据给程序的，叫做for循环。for的意思是：对于（for）每次循环，使用这些值……
预先不知道循环次数，只知道循环的结束条件的，叫做while循环，意思是：当（while）某条件判断为真的情况下，反复执行这段程序……
其实for循环是while的一个特例，例如那个从1加到100的，下面的两段程序，一个用for，一个用while，得到的结果是一样的：
>>> total = 0 >>> for i in range(1, 101): total += i >>> total 5050 >>> total = 0 >>> i = 1 >>> while i < = 100: total += i i += 1 >>> total 5050 >>>
所以我们先讲while。在Python里，while的用法是：
while 条件判断表达式: 做这个 做那个 东张西望
凹进去的这段程序，只要“条件判断表达式”为真（True），就会被反复执行。上面的累加例子里，只要i小于等于100，累加就会持续下去。
while太简单太直观了，没啥可说的，直接说for吧，for的用法是：
猛击阅读全文
