Python 工匠:使用數字與字符串的技巧

序言

這是 “Python 工匠”系列的第 3 篇文章。
數字是幾乎所有編程語言里最基本的數據類型,它是我們通過代碼連接現實世界的基礎。在 Python 里有三種數值類型:整型(int)、浮點型(float)和復數(complex)。絕大多數情況下,我們只需要和前兩種打交道。

站在用戶的角度思考問題,與客戶深入溝通,找到和田網站設計與和田網站推廣的解決方案,憑借多年的經驗,讓設計與互聯網技術結合,創造個性化、用戶體驗好的作品,建站類型包括:網站設計制作、成都網站建設、企業官網、英文網站、手機端網站、網站推廣、主機域名、網絡空間、企業郵箱。業務覆蓋和田地區。

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

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

不過,上面提到的這些都不是這篇文章的主題,如果感興趣,你可以在網上找到成堆的相關資料。在這篇文章里,我們將討論一些 更細微、更不常見 的編程實踐。來幫助你寫出更好的 Python 代碼。


內容目錄

  • 最佳實踐
    1 少寫數字字面量,使用 enum 枚舉類型改善代碼
    2 別在裸字符串處理上走太遠
    3 不必預計算字面量表達式
  • 實用技巧
    1 當多級縮進里出現多行字符串時
    2 布爾值其實也是“數字”
    3 改善超長字符串的可讀性
    4 別忘了那些 “r” 開頭的內建字符串函數
    5 使用“無窮大” float("inf")
  • 常見誤區
    1 “value = 1” 并非線程安全
    2 字符串拼接并不慢

最佳實踐

1. 少寫數字字面量

“數字字面量(integer literal)” 是指那些直接出現在代碼里的數字。它們分布在代碼里的各個角落,比如代碼 del users[0] 里的 0 就是一個數字字面量。它們簡單、實用,每個人每天都在寫。但是,當你的代碼里不斷重復出現一些特定字面量時,你的“代碼質量告警燈”就應該亮起黃燈了。

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

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 呢?這兩行代碼很簡單,沒有用到任何魔法特性。但初次接觸代碼的你可能需要花費一整個下午,才能弄懂它們的含義。
問題就出在那幾個數字字面量上。 最初寫下這個函數的人,可能是在公司成立之初加入的那位元老程序員。而他對那幾個數字的含義非常清楚。但如果你是一位剛接觸這段代碼的新人,就完全是另外一碼事了。

使用 enum 枚舉類型改善代碼

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

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

# -*- coding: utf-8 -*-
from enum import IntEnum

class TripSource(IntEnum):
    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 就完全沒有問題,因為所有人都知道它們的意思。

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 = []
    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 is not None:
        query = query.where(users.c.level >= min_level)
    if gender is not 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: 目標/源字符串是結構化的,遵循某種格式嗎?

是:找找是否已經有開源的對象化模塊操作它們,或是自己寫一個
SQL:SQLAlchemy
XML:lxml
JSON、YAML ...

否:嘗試使用模板引擎而不是復雜字符串處理邏輯來達到目的
Jinja2
mako
Mustache

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

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

def f1(delta_seconds):
    # 如果時間已經過去了超過 11 天,不做任何事
    if delta_seconds > :
        return 
    ...

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

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

我想問的是:“為什么我們不直接把代碼寫成 if delta_seconds < 11 * 24 * 3600: 呢?”

“性能”,答案一定會是“性能”。我們都知道 Python 是一門(速度欠佳的)解釋型語言,所以預先計算出 正是因為我們不想讓每次對函數 f1 的調用都帶上這部分的計算開銷。不過事實是:即使我們把代碼改成 if delta_seconds < 11 * 24 * 3600:,函數也不會多出任何額外的開銷。
Python 代碼在執行時會被解釋器編譯成字節碼,而真相就藏在字節碼里。讓我們用 dis 模塊看看:

def f1(delta_seconds):
    if delta_seconds < 11 * 24 * 3600:
        return

import dis
dis.dis(f1)

# dis 執行結果
  5           0 LOAD_FAST                0 (delta_seconds)
              2 LOAD_CONST               1 ()
              4 COMPARE_OP               0 (<)
              6 POP_JUMP_IF_FALSE       12

  6           8 LOAD_CONST               0 (None)
             10 RETURN_VALUE
        >>   12 LOAD_CONST               0 (None)
             14 RETURN_VALU

看見上面的 2 LOAD_CONST 1 () 了嗎?這表示 Python 解釋器在將源碼編譯成成字節碼時,會計算 11 * 24 * 3600 這段整表達式,并用 替換它。

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

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


實用技巧

1. 布爾值其實也是“數字”

Python 里的兩個布爾值 True 和 False 在絕大多數情況下都可以直接等價于 1 和 0 兩個整數來使用,就像這樣:

>>> True + 1
2
>>> 1 / False
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero

那么記住這點有什么用呢?首先,它們可以配合 sum 函數在需要計算總數時簡化操作:

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

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

# 類似的三元表達式:"Javascript" if 2 > 1 else "Python"
>>> ["Python", "Javascript"][2 > 1]
'Javascript'

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

單行代碼的長度不宜太長。比如 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)""")

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" '

如果使用 .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"', '')

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

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

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

如果有人問你:“Python 里什么數字最大/最小?”。你應該怎么回答?有這樣的東西存在嗎?

答案是:“有的,它們就是:float("inf")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

常見誤區

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

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

“線程安全”,通常被用來形容 某個行為或者某類數據結構,可以在多線程環境下被共享使用并產生預期內的結果。一個典型的滿足“線程安全”的模塊就是 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 時,你將為自己的直覺付出慘痛的代價。

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 告訴我吧。


往期推薦

Python 工匠:善用變量來改善代碼質量
Python 工匠:編寫條件分支代碼的技巧


藍鯨智云簡介

騰訊藍鯨智云(簡稱藍鯨)軟件體系是一套基于PaaS的技術解決方案,致力于打造行業領先的一站式自動化運維平臺。目前已經推出社區版、企業版,歡迎體驗。
請點擊訪問藍鯨官網:http://bk.tencent.com

本文名稱:Python 工匠:使用數字與字符串的技巧
網頁地址:http://m.kartarina.com/article8/dsogpip.html

成都網站建設公司_創新互聯,為您提供網站收錄全網營銷推廣網站改版網站排名Google電子商務

廣告

聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯

成都seo排名網站優化
主站蜘蛛池模板: 国产AV天堂无码一区二区三区| 中文字幕乱码人妻无码久久| 久久久久亚洲av无码专区| 东京无码熟妇人妻AV在线网址| 无码人妻精品一区二区三区东京热| 亚洲av日韩av无码av| 亚洲AⅤ无码一区二区三区在线| 亚洲国产精品无码专区影院| 成年男人裸j照无遮挡无码| 国产AV无码专区亚洲Av| 国产午夜无码视频免费网站| 无码av最新无码av专区| YY111111少妇无码理论片| 日韩精品无码区免费专区| 久久久无码人妻精品无码| 亚洲精品无码AV人在线播放| 深夜a级毛片免费无码| 无码毛片AAA在线| 国产热の有码热の无码视频| 人妻无码久久精品| 欧美性生交xxxxx无码影院∵| 69久久精品无码一区二区 | 亚洲AV无码乱码在线观看性色扶| 亚洲中久无码不卡永久在线观看| 日日摸夜夜添无码AVA片| 国产免费无码一区二区| 国产精品亚洲αv天堂无码| 无码av天天av天天爽| 内射人妻无码色AV天堂| 国产精品无码亚洲一区二区三区 | 久久亚洲AV无码精品色午夜麻豆| 东京热人妻无码一区二区av| 尤物永久免费AV无码网站| 老司机无码精品A| 无码天堂亚洲国产AV| 免费无码看av的网站| 亚洲?v无码国产在丝袜线观看| 精品无码黑人又粗又大又长| 无码专区6080yy国产电影| 日韩精品无码一区二区三区AV| 国产仑乱无码内谢|