「數字字面量(integer literal)」 是指那些直接出如今代碼裏的數字。它們分佈在代碼裏的各個角落,好比代碼 del users[0] 裏的 0 就是一個數字字面量。它們簡單、實用,每一個人天天都在寫。可是,當你的代碼裏不斷重複出現一些特定字面量時,你的「代碼質量告警燈」就應該亮起黃燈html
舉個例子,假如你剛加入一家心儀已久的新公司,同事轉交給你的項目裏有這麼一個函數:python
def mark_trip_as_featured(trip): """將某個旅程添加到推薦欄目 """ **if** trip.source== 11: do_some_thing(trip) elif trip.source== 12: do_some_other_thing(trip) ... ... **return**
這個函數作了什麼事?你努力想搞懂它的意思,不過 trip.source == 11 是什麼狀況?那 == 12 呢?這兩行代碼很簡單,沒有用到任何魔法特性。但初次接觸代碼的你可能須要花費一整個下午,才能弄懂它們的含義。程序員
問題就出在那幾個數字字面量上。 最初寫下這個函數的人,多是在公司成立之初加入的那位元老程序員。而他對那幾個數字的含義很是清楚。但若是你是一位剛接觸這段代碼的新人,就徹底是另一碼事了。sql
那麼,怎麼改善這段代碼?最直接的方式,就是爲這兩個條件分支添加註釋。不過在這裏,「添加註釋」顯然不是提高代碼可讀性的最佳辦法(其實在絕大多數其餘狀況下都不是)。咱們須要用有意義的名稱來代替這些字面量,而枚舉類型(enum)用在這裏最合適不過了。數據庫
enum 是 Python 自 3.4 版本引入的內置模塊,若是你使用的是更早的版本,能夠經過 pip install enum34 來安裝它。下面是使用 enum 的樣例代碼:編程
# -*- coding: utf-8 -*- from **enum** import IntEnum **class** TripSource(IntEum): FROM_WEBSITE= 11 FROM_IOS_CLIENT= 12 def 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**
將重複出現的數字字面量定義成枚舉類型,不光能夠改善代碼的可讀性,代碼出現 Bug 的概率也會下降。安全
試想一下,若是你在某個分支判斷時將 11 錯打成了 111 會怎麼樣?咱們時常會犯這種錯,而這類錯誤在早期特別難被發現。將這些數字字面量所有放入枚舉類型中能夠比較好的規避這類問題。相似的,將字符串字面量改寫成枚舉也能夠得到一樣的好處。性能優化
使用枚舉類型代替字面量的好處:數據結構
· 提高代碼可讀性:全部人都不須要記憶某個神奇的數字表明什麼多線程
· 提高代碼正確性:減小打錯數字或字母產生 bug 的可能性
固然,你徹底沒有必要把代碼裏的全部字面量都改爲枚舉類型。 代碼裏出現的字面量,只要在它所處的上下文裏面容易理解,就可使用它。 好比那些常常做爲數字下標出現的 0 和 -1 就徹底沒有問題,由於全部人都知道它們的意思。
什麼是「裸字符串處理」?在這篇文章裏,它指只使用基本的加減乘除和循環、配合內置函數/方法來操做字符串,得到咱們須要的結果。
全部人都寫過這樣的代碼。有時候咱們須要拼接一大段發給用戶的告警信息,有時咱們須要構造一大段發送給數據庫的 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= [] **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 語句 – 是由於這樣作簡單、直接,符合直覺。可是這樣作最大的問題在於:隨着函數邏輯變得更復雜,這段拼接代碼會變得容易出錯、難以擴展。事實上,上面這段 Demo 代碼也只是僅僅作到看上去沒有明顯的 bug 而已 (誰知道有沒有其餘隱藏問題)。
其實,對於 SQL 語句這種結構化、有規則的字符串,用對象化的方式構建和編輯它纔是更好的作法。下面這段代碼用 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 函數更短也更好維護,並且根本不須要擔憂 SQL 注入問題。因此,當你的代碼中出現複雜的裸字符串處理邏輯時,請試着用下面的方式替代它:
Q: 目標/源字符串是結構化的,遵循某種格式嗎?
· 是:找找是否已經有開源的對象化模塊操做它們,或是本身寫一個
o SQL:SQLAlchemy
o XML:lxml
o JSON、YAML …
· 否:嘗試使用模板引擎而不是複雜字符串處理邏輯來達到目的
o Jinja2
o Mako
o Mustache
咱們的代碼裏偶爾會出現一些比較複雜的數字,就像下面這樣:
def f1(delta_seconds): # 若是時間已通過去了超過 11 天,不作任何事 **if** delta_seconds> 950400: **return**
話說在前頭,上面的代碼沒有任何毛病。
首先,咱們在小本子(固然,和我同樣的聰明人會用 IPython)上算了算:11天一共包含多少秒?。而後再把結果 950400 這個神奇的數字填進咱們的代碼裏,最後心滿意足的在上面補上一行註釋:告訴全部人這個神奇的數字是怎麼來的。
我想問的是:「爲何咱們不直接把代碼寫成 if delta_seconds 呢?」
「性能」,答案必定會是「性能」。咱們都知道 Python 是一門~~(速度欠佳的)~~解釋型語言,因此預先計算出 950400 正是由於咱們不想讓每次對函數 f1 的調用都帶上這部分的計算開銷。不過事實是:即便咱們把代碼改爲****if delta_seconds ,函數也不會多出任何額外的開銷。
Python 代碼在執行時會被解釋器編譯成字節碼,而真相就藏在字節碼裏。讓咱們用 dis 模塊看看:
def f1(delta_seconds): **if** delta_seconds> 12 LOAD_CONST 0 (None) 14 RETURN_VALUE
看見上面的 2 LOAD_CONST 1 (950400) 了嗎?這表示 Python 解釋器在將源碼編譯成成字節碼時,會計算 11 * 24 * 3600 這段整表達式,並用 950400 替換它。
因此,當咱們的代碼中須要出現複雜計算的字面量時,請保留整個算式吧。它對性能沒有任何影響,並且會增長代碼的可讀性。
Hint:Python 解釋器除了會預計算數值字面量表達式之外,還會對字符串、列表作相似的操做。一切都是爲了性能。誰讓大家老吐槽 Python 慢呢?
Python 裏的兩個布爾值 True 和 False 在絕大多數狀況下均可以直接等價於 1 和 0 兩個整數來使用,就像這樣:
>>> **True**+ 1 2 >>> 1/ **False** Traceback (most recent call last): File "", line 1, **in** ZeroDivisionError: division by zero
那麼記住這點有什麼用呢?首先,它們能夠配合 sum 函數在須要計算總數時簡化操做:
>>> l= [1, 2, 4, 5, 7] >>> sum(i% 2== 0 **for** i **in** l)
此外,若是將某個布爾值表達式做爲列表的下標使用,能夠實現相似三元表達式的目的:
# 相似的三元表達式:"Javascript" if 2 > 1 else "Python" >>> ["Python", "Javascript"][2> 1] 'Javascript'
單行代碼的長度不宜太長。好比 PEP8 裏就建議每行字符數不得超過 79。現實世界裏,大部分人遵循的單行最大字符數在 79 到 119 之間。若是隻是代碼,這樣的要求是比較容易達到的,但假設代碼裏須要出現一段超長的字符串呢?
這時,除了使用斜槓 \ 和加號 + 將長字符串拆分爲好幾段之外,還有一種更簡單的辦法:使用括號將長字符串包起來,而後就能夠隨意折行了:
def main(): logger.info(("There is something really bad happened during the process. " "Please contact your administrator."))
平常編碼時,還有一種比較麻煩的狀況。就是須要在已經有縮進層級的代碼裏,插入多行字符串字面量。由於多行字符串不能包含當前的縮進空格,因此,咱們須要把代碼寫成這樣:
def main(): **if** user.is_active: message= """Welcome, today's movie list: - Jaw (1975) - The Shining (1980) - Saw (2004)"""
可是這樣寫會破壞整段代碼的縮進視覺效果,顯得很是突兀。要改善它有不少種辦法,好比咱們能夠把這段多行字符串做爲變量提取到模塊的最外層。不過,若是在你的代碼邏輯裏更適合用字面量的話,你也能夠用標準庫 textwrap 來解決這個問題:
from textwrap import dedent def main(): **if** user.is_active: # dedent 將會縮進掉整段文字最左邊的空字符串 message= dedent("""\ Welcome, today's movie list: - Jaw (1975) - The Shining (1980) - Saw (2004)""")
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),咱們須要這麼寫:
>>> 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']
若是有人問你:「Python 裏什麼數字最大/最小?」。你應該怎麼回答?有這樣的東西存在嗎?
答案是:「有的,它們就是:float("inf") 和 float("-inf")」。它們倆分別對應着數學世界裏的真負無窮大。當它們和任意數值進行比較時,知足這樣的規律:float("-inf") 。
由於它們有着這樣的特色,咱們能夠在某些場景用上它們:
# A. 根據年齡升序排序,沒有提供年齡放在最後邊 >>> 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. 做爲循環初始值,簡化第一次判斷邏輯 >>> max_num= **float**('-inf') >>> # 找到列表中最大的數字 >>> **for** i **in** [23, 71, 3, 21, 8]: ...: **if** i> max_num: ...: max_num= i ...: >>> max_num 71
當咱們編寫多線程程序時,常常須要處理複雜的共享變量和競態等問題。
「線程安全」,一般被用來形容 **某個行爲或者某類數據結構,能夠在多線程環境下被共享使用併產生預期內的結果。**一個典型的知足「線程安全」的模塊就是 queue 隊列模塊。
而咱們常作的 value += 1 操做,很容易被想固然的認爲是「線程安全」的。由於它看上去就是一個原子操做 (指一個最小的操做單位,執行途中不會插入任何其餘操做)。然而真相併不是如此,雖然從 Python 代碼上來看,value += 1 這個操做像是原子的。但它最終被 Python 解釋器執行的時候,早就再也不 「原子」 了。
咱們能夠用前面提到的 dis 模塊來驗證一下:
def incr(value): value+= 1 # 使用 dis 模塊查看字節碼 import dis dis.dis(incr) 0 LOAD_FAST 0 (value) 2 LOAD_CONST 1 (1) 4 INPLACE_ADD 6 STORE_FAST 0 (value) 8 LOAD_CONST 0 (None) 10 RETURN_VALUE
在上面輸出結果中,能夠看到這個簡單的累加語句,會被編譯成包括取值和保存在內的好幾個不一樣步驟,而在多線程環境下,任意一個其餘線程都有可能在其中某個步驟切入進來,阻礙你得到正確的結果。
所以,請不要憑藉本身的直覺來判斷某個行爲是否「線程安全」,否則等程序在高併發環境下出現奇怪的 bug 時,你將爲本身的直覺付出慘痛的代價。
我剛接觸 Python 不久時,在某個網站看到這樣一個說法: 「Python 裏的字符串是不可變的,因此每一次對字符串進行拼接都會生成一個新對象,致使新的內存分配,效率很是低」。 我對此深信不疑。
因此,一直以來,我儘可能都在避免使用 += 的方式去拼接字符串,而是用 "".join(str_list) 之類的方式來替代。
可是,在某個偶然的機會下,我對 Python 的字符串拼接作了一次簡單的性能測試後發現: Python 的字符串拼接根本就不慢! 在查閱了一些資料後,最終發現了真相。
Python 的字符串拼接在 2.2 以及以前的版本確實很慢,和我最先看到的說法行爲一致。可是由於這個操做太經常使用了,因此以後的版本里專門針對它作了性能優化。大大提高了執行效率。
現在使用 += 的方式來拼接字符串,效率已經很是接近 "".join(str_list) 了。因此,該拼接時就拼接吧,沒必要擔憂任何性能問題。
以上就是『Python 編程語言要掌握的技能之一:』系列文章的第三篇,內容比較零碎。但願你們可以喜歡,有問題歡迎你們在評論區留言
Python技術文章請關注2019年,Python技術持續更新(附教程)