您的位置 首页 科技

值得收藏的python语法总结

值得收藏的python语法总结 作者:袁昊 腾讯专项技术测试工程师2020年python2停止维护,而随着Python版本的不断更新,许多旧的语法在可读性与效率上都已经有更好的替代了。当然,大部分的重要特性,例如装饰器、生成器、async等,相信大家都已经了然于心,这里就对一些用的稍微少一些、日常看到的代码中不太常见的能用得上的语法做一个简单的笔记,供大家参考。经验有限,见解甚浅,还望各位大佬们多多指导、补充。

值得收藏的python语法总结

作者:袁昊 腾讯专项技术测试工程师

2020年python2停止维护,而随着Python版本的不断更新,许多旧的语法在可读性与效率上都已经有更好的替代了。当然,大部分的重要特性,例如装饰器、生成器、async等,相信大家都已经了然于心,这里就对一些用的稍微少一些、日常看到的代码中不太常见的能用得上的语法做一个简单的笔记,供大家参考。经验有限,见解甚浅,还望各位大佬们多多指导、补充。

2020年python2停止维护,而随着Python版本的不断更新,许多旧的语法在可读性与效率上都已经有更好的替代了。当然,大部分的重要特性,例如装饰器、生成器、async等,相信大家都已经了然于心,这里就对一些用的稍微少一些、日常看到的代码中不太常见的能用得上的语法做一个简单的笔记,供大家参考。经验有限,见解甚浅,还望各位大佬们多多指导、补充。

日常的自用Python脚本没有太大的工程压力,能紧跟更新步伐、尝试新的特性。但是语法糖用的好就是效率提升,用的不好就是可读性灾难,有些语法的出现也伴随着种种的争议,用更新的语法不代表能写出更好的代码。

值得收藏的python语法总结

翻看语言的更新日志确实蛮有意思

通过语法的更新变化还有变化带来的争议,也能窥透语言的设计哲学、汇聚浓缩在一个特定点上的社区开发经验。选择合适自己的、保持对代码精简可读的追求才是最重要。

那么就从老到新,理一理那些有意思的小feature吧。可能有漏掉有趣的点、也可能有解释不到位的地方,欢迎各位大佬更正补充。

Python 3.0-3.6 PEP 3132 可迭代对象解包拓展

Python3.0引入,加强了原本的星号运算符(*),让星号运算符能够智能地展开可迭代对象。

>>>%uA0a,%uA0*b,%uA0c%uA0=%uA0range(5)>>>%uA0a0>>>%uA0c4>>>%uA0b[1,%uA02,%uA03]

展开全文

隐式赋值也同样适用

>>>%uA0for%uA0a,%uA0*b%uA0in%uA0[(1,%uA02,%uA03),%uA0(4,%uA05,%uA06,%uA07)]:>>>%uA0%uA0%uA0%uA0%uA0print(b)[2,%uA03][5,%uA06,%uA07]

注意双星号(**)不能用相同语法展开字典

人畜无害,用处也不大的一个feature

PEP 465 矩阵乘法运算符

Python3.5引入,顾名思义,使用@符号。直接支持numpy、pandas等使用。

>>>%uA0a%uA0=%uA0numpy.array([1,%uA02,%uA03])>>>%uA0b%uA0=%uA0numpy.array([10,ꀠ,ꀰ])>>>%uA0a%uA0@%uA0b140>>>%uA0c%uA0=%uA0numpy.array([[10,ꀕ],%uA0[20,ꀥ],%uA0[30,ꀵ]])>>>%uA0d%uA0=%uA0numpy.array([[4,%uA05,%uA06],%uA0[7,%uA08,%uA09]])>>>%uA0c%uA0@%uA0darray([[145,ꀗ0,ꀙ5],%uA0%uA0%uA0%uA0%uA0%uA0%uA0[255,ꀰ0,ꀴ5],%uA0%uA0%uA0%uA0%uA0%uA0%uA0[365,ꁃ0,ꁉ5]])

矩阵乘法运算符的魔术方法为__matmul____rmatmul____imatmul__三个

本身用处不大,但是提供了一个额外的操作符使用空间,可以用来重载来进行类似距离计算之类的用途。

>>>%uA0from%uA0math%uA0import%uA0sqrt>>>%uA0class%uA0Point:>>>%uA0%uA0%uA0%uA0ꃞf%uA0__init__(self,%uA0x,%uA0y):>>>%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0self.x%uA0=%uA0x>>>%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0self.y%uA0=%uA0y>>>%uA0>>>%uA0%uA0%uA0%uA0ꃞf%uA0__matmul__(self,%uA0value):>>>%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0x_sub%uA0=%uA0self.x%uA0-%uA0value.x>>>%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0y_sub%uA0=%uA0self.y%uA0-%uA0value.y>>>%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0sqrt(x_sub**2%uA0+%uA0y_sub**2)>>>%uA0>>>%uA0a%uA0=%uA0Point(1,%uA03)>>>%uA0b%uA0=%uA0Point(4,%uA07)>>>%uA0print(a%uA0@%uA0b)5

争议主要存在于:作为矩阵乘法来说@操作符没有直观联系、影响可读性,不如直接使用matmul

PEP 3107/484/526 函数注解/类型提示/变量注解

Python3.0引入函数注解、3.5引入typing,让python也能享受静态类型的福利。可以说是py3中个人最喜欢的feature,使用简单、效果强大,直接让开发效率以及代码可维护性直线增长。

#%uA0参数后加:即可标注类型,函数结构定义后接->即可标注返回类型def%uA0get_hello(name:%uA0str)%uA0->%uA0str:%uA0%uA0%uA0%uA0return%uA0f&quotHello,%uA0{name}!”

如上进行标记之后IDE便能自动读取参数、返回类型,直接出联想爽快如java。

而PEP 484 Typing则是极大的扩充了类型定义语法,支持别名、泛型、Callable、Union等等。非常推荐直接阅读PEP。

https://www.python.org/dev/peps/pep-0484/

https://www.python.org/dev/peps/pep-0484/

下面就是一个泛型的例子

from%uA0typing%uA0import%uA0TypeVar,%uA0Iterable,%uA0TupleT%uA0=%uA0TypeVar(&aposT&apos,%uA0int,%uA0float,%uA0complex)Vector%uA0=%uA0Iterable[Tuple[T,%uA0T]]def%uA0inproduct(v:%uA0Vector[T])%uA0->%uA0T:%uA0%uA0%uA0%uA0return%uA0sum(x*y%uA0for%uA0x,%uA0y%uA0in%uA0v)def%uA0dilate(v:%uA0Vector[T],%uA0scale:%uA0T)%uA0->%uA0Vector[T]:%uA0%uA0%uA0%uA0return%uA0((x%uA0*%uA0scale,%uA0y%uA0*%uA0scale)%uA0for%uA0x,%uA0y%uA0in%uA0v)vec%uA0=%uA0[]%uA0%uA0#%uA0type:%uA0Vector[float]

随后在3.6引入了众望所归的变量注解(PEP 526),使用也很简单,直接在变量后添加冒号和类型即可,搭配函数注解一起食用体验极佳

pi:%uA0float%uA0=%uA03.142#%uA0也同样支持Union等from%uA0typing%uA0import%uA0Uniona:%uA0Union[float,None]%uA0=1.0

3.7中又引入了延迟标记求值(PEP 563),让typing支持了前向引用、并减轻了标注对程序启动时间的影响,如虎添翼。

#%uA03.7前合法class%uA0Tree:%uA0%uA0%uA0ꃞf%uA0__init__(self,%uA0left:%uA0&aposTree&apos,%uA0right:%uA0&aposTree&apos):%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0self.left%uA0=%uA0left%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0self.right%uA0=%uA0right#%uA03.7前不合法、3.7后合法class%uA0Tree:%uA0%uA0%uA0ꃞf%uA0__init__(self,%uA0left:%uA0Tree,%uA0right:%uA0Tree):%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0self.left%uA0=%uA0left%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0self.right%uA0=%uA0right

更多的python类型检查示例代码:

https://github.com/realpython/materials/tree/master/python-type-checking

https://github.com/realpython/materials/tree/master/python-type-checking

静态类型检查对Python所带来的副作用主要还是启动时间上的影响,当然大部分场景所带来的便利是远大于这一副作用的。

PEP 498 f-string

Python3.6引入,应该是用的最多的feature之一了,但是看到很多代码里面还是str.format,就不得不再提一下。

>>>%uA0a%uA0=ꀐ>>>%uA0#只需要简单的在任意字符串字面量前加个f,就可以用花括号直接引用变量>>>%uA0print(f&quota%uA0=%uA0{a}”)a%uA0=ꀐ>>>%uA0#%uA0格式化也很方便,使用:即可>>>%uA0pi%uA0=%uA03.14159>>>%uA0print(f&quotpi%uA0=%uA0{pi:%uA0.2f}”)pi%uA0=%uA03.14

也可以在表达式后接!s或者!r来选择用str还是repr方法转换为字符串。

基本就是str.format的语法糖。在3.8版本以后,又增加了直接套表达式的功能,输出信息非常方便。

>>>%uA0theta%uA0=ꀰ>>>%uA0print(f&apos{theta=}%uA0%uA0{cos(radians(theta))=:.3f}&apos)theta=30%uA0%uA0cos(radians(theta))=0.866 PEP 515 数值字面值下划线

Python3.6引入。输入太长的数字字面值怎么办?

>>>%uA0a%uA0=ꀒ3_456_789>>>%uA0b%uA0=ꀒ3456789>>>%uA0a%uA0==%uA0bTrue

比较鸡肋…

Python 3.7 PEP 557 数据类Data Classes

提供了一个方便的dataclass类装饰器,直接上代码举例:

fromꃚtaclasses%uA0importꃚtaclass@dataclassclass%uA0InventoryItem:%uA0%uA0%uA0%uA0name:%uA0str%uA0%uA0%uA0%uA0unit_price:%uA0float%uA0%uA0%uA0%uA0quantity_on_hand:%uA0int%uA0=%uA00%uA0%uA0%uA0ꃞf%uA0total_cost(self)%uA0->%uA0float:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0self.unit_price%uA0*%uA0self.quantity_on_hand

对这个例子,这个类会自动生成以下魔术方法

def%uA0__init__(self,%uA0name:%uA0str,%uA0unit_price:%uA0float,%uA0quantity_on_hand:%uA0int%uA0=%uA00)%uA0->%uA0None:%uA0%uA0%uA0%uA0self.name%uA0=%uA0name%uA0%uA0%uA0%uA0self.unit_price%uA0=%uA0unit_price%uA0%uA0%uA0%uA0self.quantity_on_hand%uA0=%uA0quantity_on_handdef%uA0__repr__(self):%uA0%uA0%uA0%uA0return%uA0f&aposInventoryItem(name={self.name!r},%uA0unit_price={self.unit_price!r},%uA0quantity_on_hand={self.quantity_on_hand!r})&aposdef%uA0__eq__(self,%uA0other):%uA0%uA0%uA0%uA0if%uA0other.__class__%uA0is%uA0self.__class__:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0(self.name,%uA0self.unit_price,%uA0self.quantity_on_hand)%uA0==%uA0(other.name,%uA0other.unit_price,%uA0other.quantity_on_hand)%uA0%uA0%uA0%uA0return%uA0NotImplementeddef%uA0__ne__(self,%uA0other):%uA0%uA0%uA0%uA0if%uA0other.__class__%uA0is%uA0self.__class__:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0(self.name,%uA0self.unit_price,%uA0self.quantity_on_hand)%uA0!=%uA0(other.name,%uA0other.unit_price,%uA0other.quantity_on_hand)%uA0%uA0%uA0%uA0return%uA0NotImplementeddef%uA0__lt__(self,%uA0other):%uA0%uA0%uA0%uA0if%uA0other.__class__%uA0is%uA0self.__class__:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0(self.name,%uA0self.unit_price,%uA0self.quantity_on_hand)%uA0<%uA0(other.name,%uA0other.unit_price,%uA0other.quantity_on_hand)%uA0%uA0%uA0%uA0return%uA0NotImplementeddef%uA0__le__(self,%uA0other):%uA0%uA0%uA0%uA0if%uA0other.__class__%uA0is%uA0self.__class__:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0(self.name,%uA0self.unit_price,%uA0self.quantity_on_hand)%uA0<=%uA0(other.name,%uA0other.unit_price,%uA0other.quantity_on_hand)%uA0%uA0%uA0%uA0return%uA0NotImplementeddef%uA0__gt__(self,%uA0other):%uA0%uA0%uA0%uA0if%uA0other.__class__%uA0is%uA0self.__class__:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0(self.name,%uA0self.unit_price,%uA0self.quantity_on_hand)%uA0>%uA0(other.name,%uA0other.unit_price,%uA0other.quantity_on_hand)%uA0%uA0%uA0%uA0return%uA0NotImplementeddef%uA0__ge__(self,%uA0other):%uA0%uA0%uA0%uA0if%uA0other.__class__%uA0is%uA0self.__class__:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0(self.name,%uA0self.unit_price,%uA0self.quantity_on_hand)%uA0>=%uA0(other.name,%uA0other.unit_price,%uA0other.quantity_on_hand)%uA0%uA0%uA0%uA0return%uA0NotImplemented

这一条PEP也是比较有争议的,主要原因是Python其实已经内置了不少的类似模型:collection.namedtupletyping.NamedTupleattrs

但是这条PEP的提出还是为了保证方便地创建资料类的同时,保证静态类型检查,而已有的方案都不方便直接使用检查器。

Python 3.8 PEP 572 海象牙运算符

值得收藏的python语法总结

“逼走”了Guido van Rossum,最有争议的PEP之一。首先引入了海象牙运算符:=,代表行内赋值。

#ꂾforewhile%uA0True:%uA0%uA0%uA0%uA0command%uA0=%uA0input(“>%uA0″)%uA0%uA0%uA0%uA0if%uA0command%uA0==%uA0&quotquit”:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0break%uA0%uA0%uA0%uA0print(&quotYou%uA0entered:”,%uA0command)%uA0%uA0%uA0%uA0#ꂯterwhile%uA0(command%uA0:=%uA0input(“>%uA0″))%uA0!=%uA0&quotquit”:%uA0%uA0%uA0%uA0print(&quotYou%uA0entered:”,%uA0command)

assignment expressions在进行分支判断时非常好用,写的时候能够舒服很多。本身使用也集中在if/while这种场景,虽然让语法变复杂了,但是总体还是可控的,舒适程度大于风险。

海象运算符本身问题不大,但是争议主要存在于PEP 572的第二点,对于生成器语义的变化。

在PEP 572后,生成器的in后的运算顺序产生了变化,原本是作为生成器输入,结果现在变成了生成器闭包的一部分。

temp_list%uA0=%uA0[&quotabc”,&quotbcd”]result_list%uA0=%uA0(x%uA0for%uA0x%uA0in%uA0range(len(temp_list)))print(list(result_list))#%uA0等价于#ꂾforetemp_list%uA0=%uA0[&quotabc”,%uA0&quotbcd”]def%uA0func_data(data:%uA0int):%uA0%uA0%uA0%uA0for%uA0x%uA0in%uA0range(data):%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0yield%uA0xresult_list%uA0=%uA0func_data(len(temp_list))print(list(result_list))#ꂯtertemp_list%uA0=%uA0[&quotabc”,%uA0&quotbcd”]def%uA0func_data:%uA0%uA0%uA0%uA0for%uA0x%uA0in%uA0range(len(temp_list)):%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0yield%uA0xresult_list%uA0=%uA0func_dataprint(list(result_list))

这样的修改目的是配合海象牙运算符增加代码可读性,但无疑是带破坏性的修改,且让运行顺序变得迷惑,让一些老代码出现难以发现的bug。

python社区在激烈辩论后,这一部分的修改被成功撤销,只保留了海象牙运算符。

关于这个PEP,知乎上有难得一见的有价值讨论,这部分范例代码也引用自此:

在函数形参处新增一个/语法,划分非关键字与关键字形参。例如

def%uA0f(a,%uA0b,%uA0/,%uA0c,%uA0d,%uA0*,%uA0e,%uA0f):%uA0%uA0%uA0%uA0print(a,%uA0b,%uA0c,%uA0d,%uA0e,%uA0f)#%uA0以下调用均合法f(10,ꀠ,ꀰ,%uA0d=40,%uA0e=50,%uA0f=60)#%uA0以下调用均不合法f(10,%uA0b=20,%uA0c=30,%uA0d=40,%uA0e=50,%uA0f=60)%uA0%uA0%uA0#%uA0bꃊnnotꂾ%uA0a%uA0keyword%uA0argumentf(10,ꀠ,ꀰ,ꁀ,ꁐ,%uA0f=60)%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0#%uA0e%uA0mustꂾ%uA0a%uA0keyword%uA0argument

/语法的添加让调用函数时可以在可读性与简洁之间自由选择,可以选择强制不接受关键字参数、不需要形参名称时也可以省略。同时也让接受任意参数函数的实现变得方便了许多,例如:

class%uA0Counter(dict):%uA0%uA0%uA0ꃞf%uA0__init__(self,%uA0iterable=None,%uA0/,%uA0**kwds):%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0#%uA0Note%uA0&quotiterable”%uA0is%uA0a%uA0possible%uA0keyword%uA0argument

这条本来也有其他方案,例如装饰器实现、def fn(.arg1, .arg2, arg3):def fn(a, (b, c), d):等,这里就不一一展开了,推荐阅读PEP原文。

Python 3.9 PEP 584 字典合并运算符

在此之前,要想合并两个字典的画风是这样的

a={&aposa&apos:1,&aposb&apos:2}b={&aposc&apos:3}a.update(b)#%uA0或者是c%uA0=%uA0{**a,%uA0**b}

但自从有了|之后,可以变成这样

a%uA0|=%uA0bc%uA0=%uA0a%uA0|%uA0b

当然这个操作符也伴随着一些争议,大概是这样:

反方:合并不符合交换律 正方:python字典合并本身就不符合交换律,特别是python3.6之后统一到有序字典后,相比合并应该更类似于拼接

反方:类似管道写法进行多次合并效率低,反复创建和销毁临时映射 正方:这种问题在序列级联时同样会出现。如果真出现了合并大量字典的使用场景,应当直接显式循环合并

反方:|操作符容易和位运算混淆。运算符行为强依赖于变量种类,这在python是非常不利于可读性的 正方:确实有这个问题,但是|已经很混乱了(位运算、集合操作、__or__魔术方法重载),所以还是先规范变量命名吧

即将到来的Python 3.10 PEP 617 / bpo-12782 括号内的上下文管理

这一条是针对with语法(PEP 343)的小变动,让一个 with可以管理多个上下文。使用也很简单

with%uA0(CtxManager%uA0as%uA0example):%uA0%uA0%uA0%uA0…with%uA0(%uA0%uA0%uA0%uA0CtxManager1,%uA0%uA0%uA0%uA0CtxManager2):%uA0%uA0%uA0%uA0…with%uA0(CtxManager1%uA0as%uA0example,%uA0%uA0%uA0%uA0%uA0%uA0CtxManager2):%uA0%uA0%uA0%uA0…with%uA0(CtxManager1,%uA0%uA0%uA0%uA0%uA0%uA0CtxManager2%uA0as%uA0example):%uA0%uA0%uA0%uA0…with%uA0(%uA0%uA0%uA0%uA0CtxManager1%uA0as%uA0example1,%uA0%uA0%uA0%uA0CtxManager2%uA0as%uA0example2):%uA0%uA0%uA0%uA0…

比较实用,避免了with下面接with产生不必要缩进的尴尬。值得注意的是,这一条语法变动是新的非LL(1)文法CPython PEG解析器所带来的副产物。所以PEP 617的标题是New PEG parser for CPython

PEP 634 结构化模式匹配match-case

直接上结构:

match%uA0subject:%uA0%uA0%uA0ꃊse%uA0&ltpattern_1>:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0&ltaction_1>%uA0%uA0%uA0ꃊse%uA0&ltpattern_2>:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0&ltaction_2>%uA0%uA0%uA0ꃊse%uA0&ltpattern_3>:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0&ltaction_3>%uA0%uA0%uA0ꃊse%uA0_:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0&ltaction_wildcard>

是不是感觉熟悉又臭名昭著的switch-case终于来了?当然还是有区别的:

这个写法基本还是if-elif-else的语法糖,运行完case就自动break出来。再加上一些看着不错的模式匹配特性。

def%uA0http_error(status):%uA0%uA0%uA0%uA0match%uA0status:%uA0%uA0%uA0%uA0%uA0%uA0%uA0ꃊseꁀ0:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0&quotBad%uA0request”%uA0%uA0%uA0%uA0%uA0%uA0%uA0ꃊseꁀ1%uA0|ꁀ3%uA0|ꁀ4:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0&quotNot%uA0allowed”%uA0%uA0%uA0%uA0%uA0%uA0%uA0ꃊseꁀ4:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0&quotNot%uA0found”%uA0%uA0%uA0%uA0%uA0%uA0%uA0ꃊseꁁ8:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0&quotI&aposm%uA0a%uA0teapot”%uA0%uA0%uA0%uA0%uA0%uA0%uA0ꃊse%uA0_:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0return%uA0&quotSomething&aposs%uA0wrong%uA0with%uA0the%uA0Internet”

这样的写法看着就比if-elif-else看着清爽了许多。针对元组、类、列表也有不错的支持:

#%uA0point%uA0is%uA0an%uA0(x,%uA0y)%uA0tuplematch%uA0point:%uA0%uA0%uA0ꃊse%uA0(0,%uA00):%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0print(&quotOrigin”)%uA0%uA0%uA0ꃊse%uA0(0,%uA0y):%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0print(f&quotY={y}”)%uA0%uA0%uA0ꃊse%uA0(x,%uA00):%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0print(f&quotX={x}”)%uA0%uA0%uA0ꃊse%uA0(x,%uA0y):%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0print(f&quotX={x},%uA0Y={y}”)%uA0%uA0%uA0ꃊse%uA0_:%uA0%uA0%uA0%uA0%uA0%uA0%uA0%uA0raise%uA0ValueError(&quotNot%uA0a%uA0point”) 结语

语言的发展是由技术的进步、工程的需求凝结出的结晶,从中透露出的是满满的代码设计哲学。充分了解语法,可以让开发变得顺畅舒适;理解了语法背后的原因与争议,则可以开拓计算机科学领域的视野。与时俱进,深入了解各种新兴技术,才是真正的极客~

What&aposs new in Python https://docs.python.org/zh-cn/3.10/whatsnew/index.html

收藏

举报

本文来自网络,不代表kpl比赛竞猜_官方App下载立场,转载请注明出处:http://www.sztld.cn/24954.html

作者: admin

为您推荐

发表评论

邮箱地址不会被公开。 必填项已用*标注

联系我们

联系我们

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部