Python 工匠：使用數字與字元串的技巧

知識 11-04

（給

Python開發者

加星標，提升Python技能

）

作者：piglei

『Python 工匠』是什麼？

我一直覺得編程某種意義上是一門『手藝』，因為優雅而高效的代碼，就如同完美的手工藝品一樣讓人賞心悅目。

在雕琢代碼的過程中，有大工程：比如應該用什麼架構、哪種設計模式。也有更多的小細節，比如何時使用異常（Exceptions）、或怎麼給變數起名。那些真正優秀的代碼，正是由無數優秀的細節造就的。

『Python 工匠』這個系列文章，是我的一次小小嘗試。它專註於分享 Python 編程中的一些偏

『小』

的東西。希望能夠幫到每一位編程路上的匠人。

系列文章：

Python 工匠：善用變數改善代碼質量

Python 工匠：編寫條件分支代碼的技巧

序言

數字是幾乎所有編程語言里最基本的數據類型，它是我們通過代碼連接現實世界的基礎。在 Python 里有三種數值類型：整型（int）、浮點型（float）和複數（complex）。絕大多數情況下，我們只需要和前兩種打交道。

整型在 Python 中比較讓人省心，因為它不區分有無符號並且永不溢出。但浮點型仍和絕大多數其他編程語言一樣，依然有著精度問題，經常讓很多剛進入編程世界大門的新人們感到困惑：「Why Are Floating Point Numbers Inaccurate?」。

相比數字，Python 里的字元串要複雜的多。要掌握它，你得先弄清楚 bytes 和 str 的區別。如果更不巧，你還是位 Python2 用戶的話，光 unicode 和字元編碼問題就夠你喝上好幾壺了（趕快遷移到 Python3 吧，就在今天！）。

不過，上面提到的這些都不是這篇文章的主題，如果感興趣，你可以在網上找到成堆的相關資料。在這篇文章里，我們將討論一些

更細微、更不常見

的編程實踐。來幫助你寫出更好的 Python 代碼。

最佳實踐

1. 少寫數字字面量

「數字字面量（integer literal）」是指那些直接出現在代碼里的數字。它們分布在代碼里的各個角落，比如代碼

del users[0]

里的

就是一個數字字面量。它們簡單、實用，每個人每天都在寫。

但是，當你的代碼里不斷重複出現一些特定字面量時，你的「代碼質量告警燈」就應該亮起黃燈 ?? 了。

舉個例子，假如你剛加入一家心儀已久的新公司，同事轉交給你的項目里有這麼一個函數：

def mark_trip_as_featured

(

trip

)

"""將某個旅程添加到推薦欄目

"""

trip

source

do_some_thing

(

trip

)

elif

trip

source

do_some_other_thing

(

trip

)

...

return

這個函數做了什麼事？你努力想搞懂它的意思，不過 trip.source == 11 是什麼情況？那 == 12 呢？這兩行代碼很簡單，沒有用到任何魔法特性。但初次接觸代碼的你可能需要花費

一整個下午

，才能弄懂它們的含義。

問題就出在那幾個數字字面量上。

最初寫下這個函數的人，可能是在公司成立之初加入的那位元老程序員。而他對那幾個數字的含義非常清楚。但如果你是一位剛接觸這段代碼的新人，就完全是另外一碼事了。

使用 enum 枚舉類型改善代碼

那麼，怎麼改善這段代碼？最直接的方式，就是為這兩個條件分支添加註釋。不過在這裡，「添加註釋」顯然不是提升代碼可讀性的最佳辦法（其實在絕大多數其他情況下都不是）。我們需要用有意義的名稱來代替這些字面量，而枚舉類型（enum）用在這裡最合適不過了。

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

# -*- coding: utf-8 -*-

from

enum

import IntEnum

class

TripSource

(

IntEum

)

FROM_WEBSITE

FROM_IOS_CLIENT

def mark_trip_as_featured

(

trip

)

trip

source

TripSource

FROM_WEBSITE

do_some_thing

(

trip

)

elif

trip

source

TripSource

FROM_IOS_CLIENT

do_some_other_thing

(

trip

)

...

return

將重複出現的數字字面量定義成枚舉類型，不光可以改善代碼的可讀性，代碼出現 Bug 的幾率也會降低。

試想一下，如果你在某個分支判斷時將

11

錯打成了

111

會怎麼樣？我們時常會犯這種錯，而這類錯誤在早期特別難被發現。將這些數字字面量全部放入枚舉類型中可以比較好的規避這類問題。類似的，將字元串字面量改寫成枚舉也可以獲得同樣的好處。

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

提升代碼可讀性
：所有人都不需要記憶某個神奇的數字代表什麼

提升代碼正確性
：減少打錯數字或字母產生 bug 的可能性

當然，你完全沒有必要把代碼里的所有字面量都改成枚舉類型。

代碼里出現的字面量，只要在它所處的上下文裡面容易理解，就可以使用它。

比如那些經常作為數字下標出現的

0

和

-1

就完全沒有問題，因為所有人都知道它們的意思。

2. 別在裸字元串處理上走太遠

什麼是「裸字元串處理」？在這篇文章里，它指

只使用基本的加減乘除和循環、配合內置函數/方法來操作字元串，獲得我們需要的結果。

所有人都寫過這樣的代碼。有時候我們需要拼接一大段發給用戶的告警信息，有時我們需要構造一大段發送給資料庫的 SQL 查詢語句，就像下面這樣：

def fetch_users

(

conn

min_level

None

gender

None

has_membership

False

sort_field

"created"

)

"""獲取用戶列表

:param int min_level: 要求的最低用戶級別，默認為所有級別

:param int gender: 篩選用戶性別，默認為所有性別

:param int has_membership: 篩選所有會員/非會員用戶，默認非會員

:param str sort_field: 排序欄位，默認為按 created "

用戶創建日期

:returns: 列表：[(User ID, User Name), ...]

"""

# 一種古老的 SQL 拼接技巧，使用 "WHERE 1=1" 來簡化字元串拼接操作

# 區分查詢 params 來避免 SQL 注入問題

statement

"SELECT id, name FROM users WHERE 1=1"

params

[]

min_level

not

None

statement

" AND level >= ?"

params

append

(

min_level

)

gender

not

None

statement

" AND gender >= ?"

params

append

(

gender

)

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 語句 – 是因為這樣做簡單、直接，符合直覺。但是這樣做最大的問題在於：

隨著函數邏輯變得更複雜，這段拼接代碼會變得容易出錯、難以擴展。

事實上，上面這段 Demo 代碼也只是僅僅做到

看上去

沒有明顯的 bug 而已 （誰知道有沒有其他隱藏問題）。

其實，對於 SQL 語句這種結構化、有規則的字元串，用對象化的方式構建和編輯它才是更好的做法。下面這段代碼用 SQLAlchemy 模塊完成了同樣的功能：

def fetch_users_v2

(

conn

min_level

None

gender

None

has_membership

False

sort_field

"created"

)

"""獲取用戶列表

"""

query

select

([

users

name

])

min_level

None

query

where

(

users

level

min_level

)

gender

None

query

where

(

users

gender

)

query

where

(

users

has_membership

order_by

(

users

[

sort_field

])

return

list

(

conn

execute

(

query

))

上面的 fetch_users_v2 函數更短也更好維護，而且根本不需要擔心 SQL 注入問題。所以，當你的代碼中出現複雜的裸字元串處理邏輯時，請試著用下面的方式替代它：

Q: 目標/源字元串是結構化的，遵循某種格式嗎？

是：找找是否已經有開源的對象化模塊操作它們，或是自己寫一個

SQL：SQLAlchemy

XML：lxml

JSON、YAML …

否：嘗試使用模板引擎而不是複雜字元串處理邏輯來達到目的

Jinja2

Mako

Mustache

3. 不必預計算字面量表達式

我們的代碼里偶爾會出現一些比較複雜的數字，就像下面這樣：

def f1

(

delta_seconds

)

# 如果時間已經過去了超過 11 天，不做任何事

delta_seconds

950400

return

...

話說在前頭，上面的代碼沒有任何毛病。

首先，我們在小本子（當然，和我一樣的聰明人會用 IPython）上算了算：11天一共包含多少秒？。然後再把結果 950400 這個神奇的數字填進我們的代碼里，最後心滿意足的在上面補上一行注釋：告訴所有人這個神奇的數字是怎麼來的。

我想問的是：「為什麼我們不直接把代碼寫成 if delta_seconds 呢？」

「性能」，答案一定會是「性能」

。我們都知道 Python 是一門~~（速度欠佳的）~~解釋型語言，所以預先計算出 950400 正是因為我們不想讓每次對函數 f1 的調用都帶上這部分的計算開銷。不過事實是：

即使我們把代碼改成 if delta_seconds ，函數也不會多出任何額外的開銷。

Python 代碼在執行時會被解釋器編譯成位元組碼，而真相就藏在位元組碼里。讓我們用 dis 模塊看看：

def f1

(

delta_seconds

)

delta_seconds

LOAD

CONST

(

None

)

RETURN_VALUE

看見上面的

2 LOAD_CONST 1 (950400)

了嗎？這表示 Python 解釋器在將源碼編譯成成位元組碼時，會計算

11 * 24 * 3600

這段整表達式，並用

950400

替換它。

所以，

當我們的代碼中需要出現複雜計算的字面量時，請保留整個算式吧。它對性能沒有任何影響，而且會增加代碼的可讀性。

Hint：Python 解釋器除了會預計算數值字面量表達式以外，還會對字元串、列表做類似的操作。一切都是為了性能。誰讓你們老吐槽 Python 慢呢？

實用技巧

1. 布爾值其實也是「數字」

Python 里的兩個布爾值

True

和

False

在絕大多數情況下都可以直接等價於

1

和

0

兩個整數來使用，就像這樣：

>>>

True

>>>

False

Traceback

(

most recent call

last

)

File

line

ZeroDivisionError

division by

zero

那麼記住這點有什麼用呢？首先，它們可以配合

sum

函數在需要計算總數時簡化操作：

>>>

[

]

>>>

sum

(

for

)

此外，如果將某個布爾值表達式作為列表的下標使用，可以實現類似三元表達式的目的：

# 類似的三元表達式："Javascript" if 2 > 1 else "Python"

>>>

[

"Python"

"Javascript"

][

]

"Javascript

2. 改善超長字元串的可讀性

單行代碼的長度不宜太長。比如 PEP8 里就建議每行字元數不得超過

。現實世界裡，大部分人遵循的單行最大字元數在 79 到 119 之間。如果只是代碼，這樣的要求是比較容易達到的，但假設代碼里需要出現一段超長的字元串呢？

這時，除了使用斜杠

和加號

+

將長字元串拆分為好幾段以外，還有一種更簡單的辦法：

使用括弧將長字元串包起來，然後就可以隨意折行了

：

def main

()

logger

info

((

"There is something really bad happened during the process. "

"Please contact your administrator."

))

當多級縮進里出現多行字元串時

日常編碼時，還有一種比較麻煩的情況。就是需要在已經有縮進層級的代碼里，插入多行字元串字面量。因為多行字元串不能包含當前的縮進空格，所以，我們需要把代碼寫成這樣：

def main

()

user

is_active

message

"""Welcome, today"s movie list:

- Jaw (1975)

- The Shining (1980)

- Saw (2004)"""

但是這樣寫會破壞整段代碼的縮進視覺效果，顯得非常突兀。要改善它有很多種辦法，比如我們可以把這段多行字元串作為變數提取到模塊的最外層。不過，如果在你的代碼邏輯里更適合用字面量的話，你也可以用標準庫

textwrap

來解決這個問題：

from textwrap import dedent

def main

()

user

is_active

# dedent 將會縮進掉整段文字最左邊的空字元串

message

dedent

(

"""

Welcome, today"s movie list:

- Jaw (1975)

- The Shining (1980)

- Saw (2004)"""

)

3. 別忘了那些「r」開頭的內建字元串函數

Python 的字元串有著非常多實用的內建方法，最常用的有

.strip()

、

.split()

等。這些內建方法里的大多數，處理起來的順序都是從左往右。但是其中也包含了部分以

r

打頭的

從右至左處理

的鏡像方法。在處理特定邏輯時，使用它們可以讓你事半功倍。

假設我們需要解析一些訪問日誌，日誌格式為：」{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)

，我們需要這麼寫：

>>>

log_line

split

()

>>>

" "

join

(

[

]),

[

]

(

""AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36""

"47632"

)

但是如果使用

.rsplit()

的話，處理邏輯就更直接了：

>>>

log_line

rsplit

(

None

)

[

""AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36""

"47632"

]

4. 使用「無窮大」 float(「inf」)

如果有人問你：「Python 里什麼數字最大/最小？」。你應該怎麼回答？有這樣的東西存在嗎？

答案是：「有的，它們就是：

float("inf")

和

float("-inf")

」。它們倆分別對應著數學世界裡的真負無窮大。當它們和任意數值進行比較時，滿足這樣的規律：

float("-inf") 。

因為它們有著這樣的特點，我們可以在某些場景用上它們：

# A. 根據年齡升序排序，沒有提供年齡放在最後邊

>>>

users

{

"tom"

"jenny"

"jack"

None

"andrew"

}

>>>

sorted

(

users

keys

(),

key

lambda

user

users

get

(

user

)

float

(

"inf"

))

[

"jenny"

"tom"

"andrew"

"jack"

]

# B. 作為循環初始值，簡化第一次判斷邏輯

>>>

max_num

float

(

"-inf"

)

>>>

# 找到列表中最大的數字

>>>

for

[

]

...

max_num

...

max_num

...

>>>

max

num

常見誤區

1. 「value += 1」並非線程安全

當我們編寫多線程程序時，經常需要處理複雜的共享變數和競態等問題。

「線程安全」，通常被用來形容

某個行為或者某類數據結構，可以在多線程環境下被共享使用併產生預期內的結果。

一個典型的滿足「線程安全」的模塊就是 queue 隊列模塊。

而我們常做的

value += 1

操作，很容易被想當然的認為是「線程安全」的。因為它看上去就是一個原子操作 （指一個最小的操作單位，執行途中不會插入任何其他操作）。然而真相併非如此，雖然從 Python 代碼上來看，

value += 1

這個操作像是原子的。但它最終被 Python 解釋器執行的時候，早就不再 「原子」 了。

我們可以用前面提到的

dis

模塊來驗證一下：

def incr

(

value

)

value

# 使用 dis 模塊查看位元組碼

import dis

dis

(

incr

)

LOAD

FAST

(

value

)

LOAD

CONST

(

)

INPLACE

ADD

STORE

FAST

(

value

)

LOAD

CONST

(

None

)

RETURN_VALUE

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

因此，請不要憑藉自己的直覺來判斷某個行為是否「線程安全」，不然等程序在高並發環境下出現奇怪的 bug 時，你將為自己的直覺付出慘痛的代價。

2. 字元串拼接並不慢

我剛接觸 Python 不久時，在某個網站看到這樣一個說法： 「Python 里的字元串是不可變的，所以每一次對字元串進行拼接都會生成一個新對象，導致新的內存分配，效率非常低」。 我對此深信不疑。

所以，一直以來，我盡量都在避免使用

+=

的方式去拼接字元串，而是用

"".join(str_list)

之類的方式來替代。

但是，在某個偶然的機會下，我對 Python 的字元串拼接做了一次簡單的性能測試後發現：

Python 的字元串拼接根本就不慢！

在查閱了一些資料後，最終發現了真相。

Python 的字元串拼接在 2.2 以及之前的版本確實很慢，和我最早看到的說法行為一致。但是因為這個操作太常用了，所以之後的版本里專門針對它做了性能優化。大大提升了執行效率。

如今使用

+=

的方式來拼接字元串，效率已經非常接近

"".join(str_list)

了。所以，該拼接時就拼接吧，不必擔心任何性能問題。

Hint: 如果你想了解更詳細的相關內容，可以讀一下這篇文章：Python – Efficient String Concatenation in Python (2016 edition) – smcl

結語

以上就是『Python 工匠』系列文章的第三篇，內容比較零碎。由於篇幅原因，一些常用的操作比如字元串格式化等，文章里並沒有涵蓋到。以後有機會再寫吧。

讓我們最後再總結一下要點：

編寫代碼時，請考慮閱讀者的感受，不要出現太多神奇的字面量

當操作結構化字元串時，使用對象化模塊比直接處理更有優勢

dis 模塊非常有用，請多多使用它驗證你的猜測

多線程環境下的編碼非常複雜，要足夠謹慎，不要相信自己的直覺

Python 語言的更新非常快，不要被別人的經驗所左右

看完文章的你，有沒有什麼想吐槽的？請留言或者在項目 Github Issues 告訴我吧。