1.少寫(xiě)數(shù)字字面量

“數(shù)字字面量（integer literal）” 是指那些直接出現(xiàn)在代碼里的數(shù)字。它們分布在代碼里的各個(gè)角落，比如代碼 del users[0] 里的 0 就是一個(gè)數(shù)字字面量。它們簡(jiǎn)單、實(shí)用，每個(gè)人每天都在寫(xiě)。但是，當(dāng)你的代碼里不斷重復(fù)出現(xiàn)一些特定字面量時(shí)，你的“代碼質(zhì)量告警燈”就應(yīng)該亮起黃燈

舉個(gè)例子，假如你剛加入一家心儀已久的新公司，同事轉(zhuǎn)交給你的項(xiàng)目里有這么一個(gè)函數(shù)：

def mark_trip_as_featured(trip):"""將某個(gè)旅程添加到推薦欄目"""**if** trip.source== 11:do_some_thing(trip)elif trip.source== 12:do_some_other_thing(trip)**return**

這個(gè)函數(shù)做了什么事？你努力想搞懂它的意思，不過(guò) trip.source == 11 是什么情況？那 == 12 呢？這兩行代碼很簡(jiǎn)單，沒(méi)有用到任何魔法特性。但初次接觸代碼的你可能需要花費(fèi)一整個(gè)下午，才能弄懂它們的含義。

問(wèn)題就出在那幾個(gè)數(shù)字字面量上。 最初寫(xiě)下這個(gè)函數(shù)的人，可能是在公司成立之初加入的那位元老程序員。而他對(duì)那幾個(gè)數(shù)字的含義非常清楚。但如果你是一位剛接觸這段代碼的新人，就完全是另外一碼事了。

使用 enum 枚舉類型改善代碼

那么，怎么改善這段代碼？最直接的方式，就是為這兩個(gè)條件分支添加注釋。不過(guò)在這里，“添加注釋”顯然不是提升代碼可讀性的最佳辦法（其實(shí)在絕大多數(shù)其他情況下都不是）。我們需要用有意義的名稱來(lái)代替這些字面量，而枚舉類型（enum）用在這里最合適不過(guò)了。

enum 是 Python 自 3.4 版本引入的內(nèi)置模塊，如果你使用的是更早的版本，可以通過(guò) pip install enum34 來(lái)安裝它。下面是使用 enum 的樣例代碼：

''' 遇到問(wèn)題沒(méi)人解答？小編創(chuàng)建了一個(gè)Python學(xué)習(xí)交流QQ群：857662006 尋找有志同道合的小伙伴， 互幫互助,群里還有不錯(cuò)的視頻學(xué)習(xí)教程和PDF電子書(shū)！ ''' # -*- coding: utf-8 -*-from **enum** import IntEnum**class** TripSource(IntEum):FROM_WEBSITE= 11FROM_IOS_CLIENT= 12def mark_trip_as_featured(trip):**if** trip.source== TripSource.FROM_WEBSITE:do_some_thing(trip)elif trip.source== TripSource.FROM_IOS_CLIENT:do_some_other_thing(trip)... ...**return**

將重復(fù)出現(xiàn)的數(shù)字字面量定義成枚舉類型，不光可以改善代碼的可讀性，代碼出現(xiàn) Bug 的幾率也會(huì)降低。

試想一下，如果你在某個(gè)分支判斷時(shí)將 11 錯(cuò)打成了 111 會(huì)怎么樣？我們時(shí)常會(huì)犯這種錯(cuò)，而這類錯(cuò)誤在早期特別難被發(fā)現(xiàn)。將這些數(shù)字字面量全部放入枚舉類型中可以比較好的規(guī)避這類問(wèn)題。類似的，將字符串字面量改寫(xiě)成枚舉也可以獲得同樣的好處。

使用枚舉類型代替字面量的好處：

· 提升代碼可讀性：所有人都不需要記憶某個(gè)神奇的數(shù)字代表什么

· 提升代碼正確性：減少打錯(cuò)數(shù)字或字母產(chǎn)生 bug 的可能性

當(dāng)然，你完全沒(méi)有必要把代碼里的所有字面量都改成枚舉類型。 代碼里出現(xiàn)的字面量，只要在它所處的上下文里面容易理解，就可以使用它。 比如那些經(jīng)常作為數(shù)字下標(biāo)出現(xiàn)的 0 和 -1 就完全沒(méi)有問(wèn)題，因?yàn)樗腥硕贾浪鼈兊囊馑肌?/p>

2. 別在裸字符串處理上走太遠(yuǎn)

什么是“裸字符串處理”？在這篇文章里，它指只使用基本的加減乘除和循環(huán)、配合內(nèi)置函數(shù)/方法來(lái)操作字符串，獲得我們需要的結(jié)果。

所有人都寫(xiě)過(guò)這樣的代碼。有時(shí)候我們需要拼接一大段發(fā)給用戶的告警信息，有時(shí)我們需要構(gòu)造一大段發(fā)送給數(shù)據(jù)庫(kù)的 SQL 查詢語(yǔ)句，就像下面這樣：

''' 遇到問(wèn)題沒(méi)人解答？小編創(chuàng)建了一個(gè)Python學(xué)習(xí)交流QQ群：857662006 尋找有志同道合的小伙伴， 互幫互助,群里還有不錯(cuò)的視頻學(xué)習(xí)教程和PDF電子書(shū)！ ''' def fetch_users(conn, min_level=None, gender=None, has_membership=**False**, sort_field="created"):"""獲取用戶列表:param int min_level: 要求的最低用戶級(jí)別，默認(rèn)為所有級(jí)別:param int gender: 篩選用戶性別，默認(rèn)為所有性別:param int has_membership: 篩選所有會(huì)員/非會(huì)員用戶，默認(rèn)非會(huì)員:param str sort_field: 排序字段，默認(rèn)為按 created "用戶創(chuàng)建日期":returns: 列表：[(User ID, User Name), ...]"""# 一種古老的 SQL 拼接技巧，使用 "WHERE 1=1" 來(lái)簡(jiǎn)化字符串拼接操作# 區(qū)分查詢 params 來(lái)避免 SQL 注入問(wèn)題statement= "SELECT id, name FROM users WHERE 1=1"params= []**if** min_level **is** **not** None:statement+= " AND level >= ?"params.append(min_level)**if** gender **is** **not** None:statement+= " AND gender >= ?"params.append(gender)**if** has_membership:statement+= " AND has_membership == true"**else**:statement+= " AND has_membership == false"statement+= " ORDER BY ?"params.append(sort_field)**return** list(conn.execute(statement, params))

我們之所以用這種方式拼接出需要的字符串 – 在這里是 SQL 語(yǔ)句 – 是因?yàn)檫@樣做簡(jiǎn)單、直接，符合直覺(jué)。但是這樣做最大的問(wèn)題在于：隨著函數(shù)邏輯變得更復(fù)雜，這段拼接代碼會(huì)變得容易出錯(cuò)、難以擴(kuò)展。事實(shí)上，上面這段 Demo 代碼也只是僅僅做到看上去沒(méi)有明顯的 bug 而已 （誰(shuí)知道有沒(méi)有其他隱藏問(wèn)題）。

其實(shí)，對(duì)于 SQL 語(yǔ)句這種結(jié)構(gòu)化、有規(guī)則的字符串，用對(duì)象化的方式構(gòu)建和編輯它才是更好的做法。下面這段代碼用 SQLAlchemy 模塊完成了同樣的功能：

def fetch_users_v2(conn, min_level=None, gender=None, has_membership=**False**, sort_field="created"):"""獲取用戶列表"""query= select([users.c.id, users.c.name])**if** min_level!= None:query= query.where(users.c.level>= min_level)**if** gender!= None:query= query.where(users.c.gender== gender)query= query.where(users.c.has_membership== has_membership).order_by(users.c[sort_field])**return** list(conn.execute(query))

上面的 fetch_users_v2 函數(shù)更短也更好維護(hù)，而且根本不需要擔(dān)心 SQL 注入問(wèn)題。所以，當(dāng)你的代碼中出現(xiàn)復(fù)雜的裸字符串處理邏輯時(shí)，請(qǐng)?jiān)囍孟旅娴姆绞教娲?#xff1a;

Q: 目標(biāo)/源字符串是結(jié)構(gòu)化的，遵循某種格式嗎？

· 是：找找是否已經(jīng)有開(kāi)源的對(duì)象化模塊操作它們，或是自己寫(xiě)一個(gè)

o SQL：SQLAlchemy

o XML：lxml

o JSON、YAML …

· 否：嘗試使用模板引擎而不是復(fù)雜字符串處理邏輯來(lái)達(dá)到目的

o Jinja2

o Mako

o Mustache

3. 不必預(yù)計(jì)算字面量表達(dá)式

我們的代碼里偶爾會(huì)出現(xiàn)一些比較復(fù)雜的數(shù)字，就像下面這樣：

''' 遇到問(wèn)題沒(méi)人解答？小編創(chuàng)建了一個(gè)Python學(xué)習(xí)交流QQ群：857662006 尋找有志同道合的小伙伴， 互幫互助,群里還有不錯(cuò)的視頻學(xué)習(xí)教程和PDF電子書(shū)！ ''' def f1(delta_seconds):# 如果時(shí)間已經(jīng)過(guò)去了超過(guò) 11 天，不做任何事**if** delta_seconds> 950400:**return**

話說(shuō)在前頭，上面的代碼沒(méi)有任何毛病。

首先，我們?cè)谛”咀?#xff08;當(dāng)然，和我一樣的聰明人會(huì)用 IPython）上算了算：11天一共包含多少秒？。然后再把結(jié)果 950400 這個(gè)神奇的數(shù)字填進(jìn)我們的代碼里，最后心滿意足的在上面補(bǔ)上一行注釋：告訴所有人這個(gè)神奇的數(shù)字是怎么來(lái)的。

我想問(wèn)的是：“為什么我們不直接把代碼寫(xiě)成 if delta_seconds 呢？”

“性能”，答案一定會(huì)是“性能”。我們都知道 Python 是一門(mén)（速度欠佳的）解釋型語(yǔ)言，所以預(yù)先計(jì)算出 950400 正是因?yàn)槲覀儾幌胱屆看螌?duì)函數(shù) f1 的調(diào)用都帶上這部分的計(jì)算開(kāi)銷。不過(guò)事實(shí)是：即使我們把代碼改成****if delta_seconds ，函數(shù)也不會(huì)多出任何額外的開(kāi)銷。

Python 代碼在執(zhí)行時(shí)會(huì)被解釋器編譯成字節(jié)碼，而真相就藏在字節(jié)碼里。讓我們用 dis 模塊看看：

def f1(delta_seconds):**if** delta_seconds> 12 LOAD_CONST 0 (None)14 RETURN_VALUE

看見(jiàn)上面的 2 LOAD_CONST 1 (950400) 了嗎？這表示 Python 解釋器在將源碼編譯成成字節(jié)碼時(shí)，會(huì)計(jì)算 11 * 24 * 3600 這段整表達(dá)式，并用 950400 替換它。

所以，當(dāng)我們的代碼中需要出現(xiàn)復(fù)雜計(jì)算的字面量時(shí)，請(qǐng)保留整個(gè)算式吧。它對(duì)性能沒(méi)有任何影響，而且會(huì)增加代碼的可讀性。

Hint：Python 解釋器除了會(huì)預(yù)計(jì)算數(shù)值字面量表達(dá)式以外，還會(huì)對(duì)字符串、列表做類似的操作。一切都是為了性能。誰(shuí)讓你們老吐槽 Python 慢呢？

實(shí)用技巧

1. 布爾值其實(shí)也是“數(shù)字”

Python 里的兩個(gè)布爾值 True 和 False 在絕大多數(shù)情況下都可以直接等價(jià)于 1 和 0 兩個(gè)整數(shù)來(lái)使用，就像這樣：

''' 遇到問(wèn)題沒(méi)人解答？小編創(chuàng)建了一個(gè)Python學(xué)習(xí)交流QQ群：857662006 尋找有志同道合的小伙伴， 互幫互助,群里還有不錯(cuò)的視頻學(xué)習(xí)教程和PDF電子書(shū)！ ''' >>> **True**+ 12>>> 1/ **False**Traceback (most recent call last):File "", line 1, **in**ZeroDivisionError: division by zero

那么記住這點(diǎn)有什么用呢？首先，它們可以配合 sum 函數(shù)在需要計(jì)算總數(shù)時(shí)簡(jiǎn)化操作：

>>> l= [1, 2, 4, 5, 7]>>> sum(i% 2== 0 **for** i **in** l)

此外，如果將某個(gè)布爾值表達(dá)式作為列表的下標(biāo)使用，可以實(shí)現(xiàn)類似三元表達(dá)式的目的：

# 類似的三元表達(dá)式："Javascript" if 2 > 1 else "Python">>> ["Python", "Javascript"][2> 1]'Javascript'

2. 改善超長(zhǎng)字符串的可讀性

單行代碼的長(zhǎng)度不宜太長(zhǎng)。比如 PEP8 里就建議每行字符數(shù)不得超過(guò) 79。現(xiàn)實(shí)世界里，大部分人遵循的單行最大字符數(shù)在 79 到 119 之間。如果只是代碼，這樣的要求是比較容易達(dá)到的，但假設(shè)代碼里需要出現(xiàn)一段超長(zhǎng)的字符串呢？

這時(shí)，除了使用斜杠 \ 和加號(hào) + 將長(zhǎng)字符串拆分為好幾段以外，還有一種更簡(jiǎn)單的辦法：使用括號(hào)將長(zhǎng)字符串包起來(lái)，然后就可以隨意折行了：

''' 遇到問(wèn)題沒(méi)人解答？小編創(chuàng)建了一個(gè)Python學(xué)習(xí)交流QQ群：857662006 尋找有志同道合的小伙伴， 互幫互助,群里還有不錯(cuò)的視頻學(xué)習(xí)教程和PDF電子書(shū)！ ''' def main():logger.info(("There is something really bad happened during the process. ""Please contact your administrator."))

當(dāng)多級(jí)縮進(jìn)里出現(xiàn)多行字符串時(shí)

日常編碼時(shí)，還有一種比較麻煩的情況。就是需要在已經(jīng)有縮進(jìn)層級(jí)的代碼里，插入多行字符串字面量。因?yàn)槎嘈凶址荒馨?dāng)前的縮進(jìn)空格，所以，我們需要把代碼寫(xiě)成這樣：

def main():**if** user.is_active:message= """Welcome, today's movie list:- Jaw (1975)- The Shining (1980)- Saw (2004)"""

但是這樣寫(xiě)會(huì)破壞整段代碼的縮進(jìn)視覺(jué)效果，顯得非常突兀。要改善它有很多種辦法，比如我們可以把這段多行字符串作為變量提取到模塊的最外層。不過(guò)，如果在你的代碼邏輯里更適合用字面量的話，你也可以用標(biāo)準(zhǔn)庫(kù) textwrap 來(lái)解決這個(gè)問(wèn)題：

from textwrap import dedentdef main():**if** user.is_active:# dedent 將會(huì)縮進(jìn)掉整段文字最左邊的空字符串message= dedent("""\Welcome, today's movie list:- Jaw (1975)- The Shining (1980)- Saw (2004)""")

3. 別忘了那些 “r” 開(kāi)頭的內(nèi)建字符串函數(shù)

Python 的字符串有著非常多實(shí)用的內(nèi)建方法，最常用的有 .strip()、.split() 等。這些內(nèi)建方法里的大多數(shù)，處理起來(lái)的順序都是從左往右。但是其中也包含了部分以 r 打頭的從右至左處理的鏡像方法。在處理特定邏輯時(shí)，使用它們可以讓你事半功倍。

假設(shè)我們需要解析一些訪問(wèn)日志，日志格式為：”{user_agent}” {content_length}：

>>> log_line= '"AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36" 47632'

如果使用 .split() 將日志拆分為 (user_agent, content_length)，我們需要這么寫(xiě)：

>>> l= log_line.split()>>> " ".join(l[:-1]), l[-1]('"AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"', '47632')

但是如果使用 .rsplit() 的話，處理邏輯就更直接了：

>>> log_line.rsplit(None, 1)['"AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36"', '47632']

4. 使用“無(wú)窮大” float(“inf”)

如果有人問(wèn)你：“Python 里什么數(shù)字最大/最小？”。你應(yīng)該怎么回答？有這樣的東西存在嗎？

答案是：“有的，它們就是：float(“inf”) 和 float("-inf")”。它們倆分別對(duì)應(yīng)著數(shù)學(xué)世界里的真負(fù)無(wú)窮大。當(dāng)它們和任意數(shù)值進(jìn)行比較時(shí)，滿足這樣的規(guī)律：float("-inf") 。

因?yàn)樗鼈冇兄@樣的特點(diǎn)，我們可以在某些場(chǎng)景用上它們：

# A. 根據(jù)年齡升序排序，沒(méi)有提供年齡放在最后邊>>> users= {"tom": 19, "jenny": 13, "jack": None, "andrew": 43}>>> sorted(users.keys(), key=lambda user: users.get(user) **or** **float**('inf'))['jenny', 'tom', 'andrew', 'jack']# B. 作為循環(huán)初始值，簡(jiǎn)化第一次判斷邏輯>>> max_num= **float**('-inf')>>> # 找到列表中最大的數(shù)字>>> **for** i **in** [23, 71, 3, 21, 8]:...: **if** i> max_num:...: max_num= i...:>>> max_num

常見(jiàn)誤區(qū)

1. “value += 1” 并非線程安全

當(dāng)我們編寫(xiě)多線程程序時(shí)，經(jīng)常需要處理復(fù)雜的共享變量和競(jìng)態(tài)等問(wèn)題。

“線程安全”，通常被用來(lái)形容 某個(gè)行為或者某類數(shù)據(jù)結(jié)構(gòu)，可以在多線程環(huán)境下被共享使用并產(chǎn)生預(yù)期內(nèi)的結(jié)果。一個(gè)典型的滿足“線程安全”的模塊就是 queue 隊(duì)列模塊。

而我們常做的 value += 1 操作，很容易被想當(dāng)然的認(rèn)為是“線程安全”的。因?yàn)樗瓷先ゾ褪且粋€(gè)原子操作 （指一個(gè)最小的操作單位，執(zhí)行途中不會(huì)插入任何其他操作）。然而真相并非如此，雖然從 Python 代碼上來(lái)看，value += 1 這個(gè)操作像是原子的。但它最終被 Python 解釋器執(zhí)行的時(shí)候，早就不再 “原子” 了。

我們可以用前面提到的 dis 模塊來(lái)驗(yàn)證一下：

''' 遇到問(wèn)題沒(méi)人解答？小編創(chuàng)建了一個(gè)Python學(xué)習(xí)交流QQ群：857662006 尋找有志同道合的小伙伴， 互幫互助,群里還有不錯(cuò)的視頻學(xué)習(xí)教程和PDF電子書(shū)！ ''' def incr(value):value+= 1# 使用 dis 模塊查看字節(jié)碼import disdis.dis(incr)0 LOAD_FAST 0 (value)2 LOAD_CONST 1 (1)4 INPLACE_ADD6 STORE_FAST 0 (value)8 LOAD_CONST 0 (None)10 RETURN_VALUE

在上面輸出結(jié)果中，可以看到這個(gè)簡(jiǎn)單的累加語(yǔ)句，會(huì)被編譯成包括取值和保存在內(nèi)的好幾個(gè)不同步驟，而在多線程環(huán)境下，任意一個(gè)其他線程都有可能在其中某個(gè)步驟切入進(jìn)來(lái)，阻礙你獲得正確的結(jié)果。

因此，請(qǐng)不要憑借自己的直覺(jué)來(lái)判斷某個(gè)行為是否“線程安全”，不然等程序在高并發(fā)環(huán)境下出現(xiàn)奇怪的 bug 時(shí)，你將為自己的直覺(jué)付出慘痛的代價(jià)。

2. 字符串拼接并不慢

我剛接觸 Python 不久時(shí)，在某個(gè)網(wǎng)站看到這樣一個(gè)說(shuō)法： “Python 里的字符串是不可變的，所以每一次對(duì)字符串進(jìn)行拼接都會(huì)生成一個(gè)新對(duì)象，導(dǎo)致新的內(nèi)存分配，效率非常低”。 我對(duì)此深信不疑。

所以，一直以來(lái)，我盡量都在避免使用 += 的方式去拼接字符串，而是用 “”.join(str_list) 之類的方式來(lái)替代。

但是，在某個(gè)偶然的機(jī)會(huì)下，我對(duì) Python 的字符串拼接做了一次簡(jiǎn)單的性能測(cè)試后發(fā)現(xiàn)： Python 的字符串拼接根本就不慢！ 在查閱了一些資料后，最終發(fā)現(xiàn)了真相。

Python 的字符串拼接在 2.2 以及之前的版本確實(shí)很慢，和我最早看到的說(shuō)法行為一致。但是因?yàn)檫@個(gè)操作太常用了，所以之后的版本里專門(mén)針對(duì)它做了性能優(yōu)化。大大提升了執(zhí)行效率。

如今使用 += 的方式來(lái)拼接字符串，效率已經(jīng)非常接近 “”.join(str_list) 了。所以，該拼接時(shí)就拼接吧，不必?fù)?dān)心任何性能問(wèn)題。

總結(jié)

以上是生活随笔為你收集整理的Python使用数字与字符串的技巧的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。