时隔一个月，没错，本系列又要更新啦。小甲鱼年更系列31集已经看完，接下来就是啃这本《Python编程：从入门到实践》。其实小甲鱼有老版的python教程，配套第一版和第二版的《从零开始学python》。but当前的最新版教程其实配套的是尚未出版的第三版教程书。
所以从喜新不喜旧的角度上来讲，没有第三版的教程书和配套视频，我也并不愿意回去看老版内容。
索性手里还有这本《ython编程：从入门到实践》，那就先看着吧。以后如果被卡住了，那就再回去看看其他教程视频。
2.4 数
2.4.1 整数
在编程中，经常使用数来记录得分、表示可视化数据、存储Web应用信息，等等。Python能根据数的用法以不同的方式处理它们。鉴于整数使用起来最简单，下面就先来看看Python是怎么管理它们的。
在Python中，可对整数执行加+减-乘*除/运算。乘方为**。
Python还支持运算次序，因此可在不同表达式中使用多种运算。还可以使用圆括号来修改运算次序。
示例：
>>> 3 * 4 +(3 * 4)
24这个作为中国人来讲很好理解啦。小学生都知道，有计算算式是由左到右，有圆括号优先计算括号内。
2.4.2 浮点数
Python将所有带小数点的数称为浮点数。大多数编程语言使用了这个术语，它指出了这样一个事实：小数点可以出现在现在数的任何位置。每种编程语言都必须细心设计，以妥善地处理浮点数，确保不管小数点出现在什么位置，数的行为都是正常的。
从很大程度上说，使用浮点数时无需考虑其行为。你只需输入要使用的数，Python通常会按你期望的方式处理它们。教科书最大的问题就是这个，就是为了描述准确及不出错，所以必须要使用学科语言。这就导致很好理解的东西，书里总是写的很复杂。
简单来说就是有小数点的数呗，并且不能点错。比如可以0.1，不能.01。这样就是错的。
但需要注意的是，结果包含的小数位数可能是不确定的。
示例：
>>> 0.1+0.2
0.30000000000000004
>>> 3*0.1
0.30000000000000004
所有语言都存在这种问题，没有什么可担心的。Python会尽力找到一种精确表达结果的方式，但鉴于计算机内部表示数的方式，这在有些情况下很难。就现在而言，暂时忽略多余的小数位数即可。在第二部分的项目中，你将在需要时学习处理多余小数位的方式。如果有看过我《从0开始学Python》的同学，应该就知道这个问题出现在哪了。我摘录一段，内容如下：
Python里的浮点数在计算结果非整数的时候，会不准。比如0.1+0.2=0.30000000(一串0)4.没道理啊，中国人都知道0.1+0.2=0.3啊，这是因为计算机是二进制的，十进制的数字在二进制的存储里会有无尽的情况。这个在十进制里也很常见，比如1➗3，就是除不尽的0.333333……。所以在非整数的计算中，如果要求结果特别精确，就不能直接使用0.1+0.2的算法。而是要先定义。
import decimal #调用decimal a = decimal.Decimal("0.1") #为a赋值精确的0.1 b = decimal.Decimal("0.2") #为b赋值精确的0.2 print(a+b) #打印a+b的结果只有这样才能得到0.3的结果。
从0开始学Python（03）：浮点数与运算函数
2.4.3 整数和浮点数
将任意两个数相除时，结果总是浮点数，即便这两个数都是整数且能整除。
>>> 4/2
2.0
在其他任何运算中，如果一个操作数是整数，另一个操作数是浮点数，结果也总是浮点数：
>>> 1+2.0
3.0
>>> 2+3.0
5.0
无论是哪种运算，只要有操作数是浮点数，Python默认得到的总是浮点数，即便结果原本为整数也是如此。在上文中没有提到的，如果是两个整数相加，或相乘，就不会出现浮点数。
>>> 1+2
3
>>> 3*4
122.4.4 数中的下划线
书写很大的数时，可使用下划线将其中的数字分组，使其更清晰易读：
universe_age = 14_000_000_000
当你打印这种使用下划线定义的数时，Python不会打印其中的下划线。
>>> print(universe_age)
14000000000
这是因为存储这种数时，Python会忽略其中的下划线。将数字分组时，即便不是将每三位分成一组，也不会影响最终的值。在Python看来，1000与1_000没什么不同，1_000与10_00也没什么不同。这种表示法适用于整数和浮点数，但只有Python 3.6和更高版本支持这里说句题外话，老外是每三个零加个分隔符。比如1000，老外写就是1，000。这种习惯现在国内也学了不少，比如我们说工资，不说一万，两万，而说10k，20k。我一直是觉得按照我们的习惯，就算要加分隔符，也是四个0000。这样，1，0000就是一万。1，0000，0000就是一亿。好了扯远了，课间休息时间已过，我们继续。
2.4.5 同时给多个变量赋值
可在一行代码中给多个变量赋值，这有助于缩短程序并提高其可读性。这种做法最常用于将一系列数赋给一组变量。
例如，下面演示了如何将变量x，y，z都初始化为零：
x,y,z = 0，0，0
这样做时，需要用逗号将变量名分开；对于要赋值给变量的值，也需同样处理。Python将按顺序将每个值赋给对应的变量。只要变量和值的个数相同，Python就能正确地将它们关联起来。2.4.6 常量
常量类似于变量，但其值在程序的整个生命周期内保持不变。Python没有内置的常量类型，但Python程序员会使用全大写来支出应将某个变量视为常量，其值应始终不变。
MAX_CONNECTIONS = 5000
在代码中，要指出应将特定的变量视为常量，可将其字母全部大写。2.5 注释
在大多数编程语言中，注释是一项很有用的功能。本书前面编写的程序中都只包含Python代码，但随着程序越来越大、越来越复杂，就应在其中添加说明，对你解决问题的方法进行大致阐述。注释让你能够使用自然语言在程序中添加说明。
2.5.1 如何编写注释
在Python中，注释用#标识。井号后面的内容都会被Python解释器忽略，如下所示：
# 向大家问好
print("Hello Python people!")
Python解释器将忽略第一行，只执行第二行。
Hello Python people!这里多插一句，打印的意思就是将代码输出。print(“Hello Python people!”)就是输出字符串Hello Python people!。
2.5.2 该编写什么样的注释
编写注释的主要目的是阐述代码要做什么，以及是如何做的。在开发项目期间，你对各个部分如何协同了如指掌，但过段时间后，有些细节你可能已经不记得了。当然，你总是可以通过研究代码来确定各部分工作原理，但通过编写注释以清晰的自然语言对解决方案进行概述，可以节省很多时间。
......（省略两段描述注释有多重要的内容）我在《从0开始学Python》中就大量使用注释，一方面对于新人而言，不要高估自己解读代码的能力。很多作业，第二天我就忘记啥意思了。另一方面也要养成习惯，要养成写代码的时候加注释的习惯。
其实很多程序员都不怎么加注释，原因在于加注释并不能增快项目进度，反而会降低开发速度。且还不能给自己加分，拿个好绩效。大多数情况下注释的核心作用都是给后面接盘的人看的（少部分也有自己时隔多年回去补坑的痛苦）。
那么问题就来了，后面接盘的人懂不懂，会不会，跟自己有啥关系。那个时候自己都可能离职、转岗、高升了，所以写注释吃力不讨好嘛。经过五年十年，无数个程序员在代码上修修改改，增增补补，各种不加注释，就会形成”看代码一天，写代码一个小时“的极低效率。当业务方对这个效率表示抗议，进而表示愤怒的时候。
程序员就会一脸无辜的说：”那就重构喽。“然后半年就出去了，业务方半年里维持最小技术支持，大堆技术资源要去重构。技术员要疯狂996，保证在deadline之前重构完。
啊~这就是血与泪的教训啊。
不过看到我上面所写的原因，又有谁真的愿意花自己的开发时间去给后来人乘凉呢？别闹了，继续加班吧。
2.6 Python之禅
经验丰富的程序员倡导尽可能避繁就简。Python社区的理念都包含在Tim Peters撰写的”Python之禅“中。要获悉这些有关编写Python代码的指导原则。只需在解释器中执行命令import this。这里不打算赘述整个”python之禅“，而只与大家分享其中的几条原则，让你明白为何他们对Python新手来说至关重要。附Python之禅原文：
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
附Python之禅的中文翻译版：
优美胜于丑陋（Python 以编写优美的代码为目标）
明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）
可读性很重要（优美的代码是可读的）
即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写 except:pass 风格的代码）
当存在多种可能，不要尝试去猜测
而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）
虽然这并不容易，因为你不是 Python 之父（这里的 Dutch 是指 Guido ）
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）看不懂吧，我也看不懂，看看书里是怎么说的吧。
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Python程序员笃信代码可以编写得漂亮而优雅。变成是要解决问题的，设计良好、高效而漂亮的解决方案都会让程序员心生敬意。随着你对Python的认识越来越深入，并使用它来编写越来越多的代码，有一天也许会有人站在你背后惊呼：”哇，代码编写的真是漂亮！“这…真的会有人说吗？
Simple is better than complex.
如果你有两个解决方案，一个简单、一个复杂，但都行之有效，就选择简单的解决方案吧。这样你编写的代码将更容易维护，你或他人以后改进这些代码时也会更容易。
Complex is better than complicated.
现实是复杂的，有时候可能没有简单的解决方案。在这种情况下，就选择最简单可行的解决方案吧。
Readability counts.
即便是复杂的代码，也要让它易于理解。开发的项目涉及复杂代码时，一定要为这些代码编写有益的注释。
There should be one-- and preferably only one --obvious way to do it.
如果让两名Python程序员去解决同一个问题，他们提供的解决的方案大致相同。这并不是说编程没有创意空间，而是恰恰相反！然而，大部分编程工作是使用常见解决方案来解决简单的小问题，但这些小问题都包含在更庞大、更有创意空间的项目中。在你的程序中，各种具体细节对其他Python程序员来说都应易理解。
Now is better than never.
你可以用余生来学习Python和编程的纷繁难懂之处，但这样你什么项目都完不成。不要企图编写完美无缺的代码，而是要先编写行之有效的代码，再决定是对其做进一步改进，还是转而编写新代码。
等你进入下一章，开始研究更复杂的主题时，务必牢记这种简约而清晰的理念。如此，经验丰富的程序员定将你编写的代码心生敬意，进而乐意向你提供反馈，并与你合作开发有趣的项目。第二章的内容就是这些啦，粗学了小甲鱼的教程再学这个，初期会少很多坎坷。特别是对于纯小白来说，优先看视频讲解还是更好入门一些。
下一章的内容主要是列表，这也是我们的老朋友了。我们下章再见~
胭惜雨
2021年01月27日