Re: [討論] Python 3.10將加入Switch-Case語句
※ 引述《ohmylove347 (米特巴爾)》之銘言:
: https://reurl.cc/8yzA24
: 上面說2006年 PEP 3103就建議實施switch-case語句。
: 但是,在PyCon 2007上的一項民意調查未獲得對該功能的支持後,
: Python開發人員將其刪除。
:
: 沒有使用Python不知道生態系如何
: Google App上看到的文章
: 不知道各位大大對Switch加入有什麼看法
:
: 推 Muscovy: for/while 比 if-else 常出現無誤, 大概 10:1 的比例. XD
: 推 TAMSHUI: 不知M大能否舉例完全不用if-else呢?Google了一下還是沒
: → TAMSHUI: 什麼想法@@
: 推 Muscovy: 不會到完全不寫 if 的程度啦,等一下我來整理一篇
我的工作環境很雜, 從 matlab 到 C 與他的親朋好友(java 也算. :D)
反正猴子用 C, 有錢的猴子用 matlab, 沒錢的猴子像我就用 python.
但是大概都會雙棲...
我來舉個例子...
譬如你有一組數字, 數量不多不少, 大約 10,000 個左右.
然後要處理它, 先叫他 eigen_spectrum, 或者簡稱 eig 好了.
當 eigen_spectrum >= 100,000,000 的時候要做一堆事.
介於 [10, 100,000,000) 的時候又一堆事.
介於 (0, 10) 的時候又一堆.
剛好等於 0 的時候需要處理特殊事件.
然後小於 0 的話要檢查有沒有奇怪的現象, 標注一些警示.
這些事情的執行細節通通都不太一樣, 然後要怎麼做?
用 C 的話, 大概 if-else/if-else/if-...-else 之外就沒招了.
所以 python by C programmer 會變這樣:
for s in eigen_spectrum:
if s >= 1e8:
pass # 這裡寫一大坨, 頂多寫個函數處理.
elif s >= 10 and s < 1e8:
pass # 這裡再一坨, 或者寫個跟上面不一樣函數.
elif s > 0 and s < 10:
pass # 再一坨, 或者再一個跟上面都不同的函數.
elif s == 0:
pass # 嗯, 你知道的, 繼續.
elif s < 0:
pass # 嗯......寫就對了.
else:
raise ValueError("Should not happen.")
最後你會得到一堆只用一次的函數, 或者一大串超長程式碼.
但是 python programmer 呢, 會這樣寫:
for s in eig[eig > 1e8]:
pass # 寫寫寫, 也是一大坨.
for s in eig[np.logical_and(eig > 10, eig < 1e8)]:
pass # 繼續寫寫寫, 也是一坨.
for s in eig[np.logical_and(eig > 0, eig < 10)]:
pass # 再寫, 繼續就對了.
if np.any(eig == 0):
pass # 驚醒! 想一下遇上 0 的時候要做什麼.
for s in eig[eig < 0]:
pass # 再寫再寫, 反正就是接龍.
很有趣的結構吧? 你還是會變出一段超長程式碼.
再加上明明一個迴圈可以搞定的事, 硬要拆成四個.
還補了一個莫名其妙, 不太對稱的 if.
但事實上這種寫法比較好維護, 因為這個結構更近似數學的模型.
可以往前翻到我上面的文字敘述, 比看看兩種寫法就知道了.
這個數學模型很簡單, 然而不同的寫法就已經有風格上的區分.
稍微複雜一點的數學模型, 用 if-elif-else 就更難重建.
譬如這個 eigen_spectrum 會有一組伴隨的 eigen_states 要處理.
用 if-else 硬爬會爬出一堆腦袋打結的程式碼, 因為很不像數學.
然後結構裡面的 if 其實是用來做 s == 0, exception handle.
而且這也是我最常遭遇的情境: 用 if + raise 來表示異常狀況.
其他時候, 我一下子想不太到寫 if statement 的情況.
因為翻到的程式碼幾乎都是:
if np.count_nonzero(np.abs(s) < 1e-8) > 2:
raise ValueError('Too many singularities.')
這一類的東西, 它就是有個 raise.
: → as30385438: 不用if就是用loop、dict的key放condition或一些DP手法
: → as30385438: 寫python的常常追求所謂的pythonic,不過我自己是覺得
: → as30385438: simple is best,最直覺的寫法通常就是最好的
從 stackoverflow 容易學到的毛病就是把 one-liner 當成 pythonian.
養成這種習慣的程式員有夠難矯正.
--
新詩練習:新鮮。踩破初春裡的狗大便;不經意的滄桑,滿溢著嫩黃的喜悅。
--
請問這是使用 numpy 嗎?
for 迴圈的範例那邊
是. python 內建的也有類似的寫法, 但 numpy 比較簡潔.
好像是滿好玩的 關心值 不知道會不會比較有效果
變成5次for好在哪裡
第二種其實 eig 會被 scan 五次?效能不是比較差嗎
我是python progammer但是我用if else 不會用5n迴圈
看起來似乎比較好懂,但效能比較差的樣子
其實第二個可讀性沒比第一個好 後人還會覺得幹嘛不用一個
迴圈
你若要raise ex,第二種更難讀出何時會 raise ex
然後如果你 pass 裡面資料是不能被重複處理的,在第二種
case 若條件有 overlap 會出 bug
不太懂為什麼第二個會比較好維護? Python也可以用第
一種寫法不是嗎?
明明就if-else比較好維護吧...
“pythonic”
我也選 if else
覺得第二種不好讀
第二種以維護角度比較容易, 第一種當條件混入各種可能後
會很難知道甚麼時候會跑到哪個條件
只要考慮到有情形是多個條件都能成立時,第一種寫法就是
看執行順序,而第二種寫法會變成餵進來的資料都是符合條
見的
多條件你就用多個if就好不用else了 = =
補充一下 多條件指可能你的condition並非完全互斥
又是一個不考慮CPU如何branch的人
NO 你先if排除不符合的條件更直觀也有更好的效能
我知道你是想遵循單一職責原則,但這不是定律
一個迴圈做多個判斷沒有不行 你判斷式提取為函式就好
樓上說到一個重點...if的位置在某些情況可以大幅改善效能
你去看pandas的源碼吧 一個for loop裡面包山包海的code一堆
例如在迴圈的一開始就篩掉大部分 case 並 continue
先寫的簡單好懂比效能重要 推推
樓上說的這叫early return,寫可讀性高的程式常用到
for in 後面的條件不會先被展開嗎 這樣不是比較慢?
然後第二種寫寫一大長串不是很難看嗎 第一種雖然一堆
一次性的func 但拿來命名可以清楚看出他是要幹麼的
以這個例子而言 的確1的寫法不會比較差 就是分區而已
但複雜情況2的維護性會高不少
in 後面計算量通常不大(跟裡面那堆比),拿去profiling
就知道了
4
話說我只是想分享一下我前一陣子在 twitter 上面看到的討論 簡短的來說就是某 PL 強者認真的研究了一下 PEP 622,然後提出了質疑。 (對,我知道不是 635 但我只是要分享這件有趣的事情) 先附上原文: TL;DR 是這樣的8
一回神竟然引發這些有趣的討論. 來稍微介紹一下我的工作背景: 我是在上市公司做高效能運算的單位主管. 算什麼無聊東西就不要問了, 不過特別強調, 不是博弈或者加密貨幣. :D 我的一個 block 通常會吃掉 100%~500% CPU, 生命期介於 2~48 hours. 執行階段佔用記憶體大概是 20GB~30GB 之間, 偶爾會用到 memory map.1
我個人是很討厭很多if-else, 或是switch case. 並不是說不好, 只是很容易出現有些section是code, 有些是function. 案子急一點, 重覆的code就會很多. 幾百個if-else/switch-case就有機會變成上萬行的code. 這個就很阿雜了. 就之前數字區間的code, 我是會往這個方向走8
討論這麼熱烈 可是各位有點進去把它看完嗎XD Python 3.10 的 Structural Pattern Matching 不是單純的 switch-case 而已 它的 case 裡是還可以放變數給它賦值的(不知道怎麼準確描述 舉個官網的例子,還可以這樣用:22
首Po上面說2006年 PEP 3103就建議實施switch-case語句。但是,在PyCon 2007上的一項民意調查未獲得對該功能的支持後,Python開發人員將其刪除。 沒有使用Python不知道生態系如何 Google App上看到的文章 不知道各位大大對Switch加入有什麼看法
85
[問卦] 代問:如何寫出讓人看不懂的Python程式碼?繼上集, 朋友被指導教授要求給博後論文草稿和實驗程式碼之後, 朋友除了使用推文有建議的拖,慢,等戰術讓博後拿不到, 78博後對我朋友出了新招,36
[問卦] 到網路上參考程式寫法會良心不安嗎?老師出了一個簡單的python 作業啦, 小弟大概知道要怎麼解, 用哪些函數。 可是實際執行, bug一大堆。32
[請益] 代問:如何寫出讓人看不懂的Python程式碼?繼上集, 朋友被指導教授要求給博後論文草稿和實驗程式碼之後, 朋友除了使用推文有建議的拖,慢,等戰術讓博後拿不到, 78博後對我朋友出了新招,10
[問題] 河口湖班次想請問3/18要去河口湖 有購買jr pass廣域先上網預約新宿到下吉田 早上8:30從新宿出發的車 想說到下吉田先下車拍照 但從下吉田到河口湖的部分8
[請益] 資工所資演的語言各位先進大家好, 想請教一下資工所其中的資料結構演算法這科,如果有需要寫程式碼的部分,有規定使用 什麼語言嗎? 我學校學這科的時候是用Python, 不確定可不可以使用,如果不行,現在要開始學一個可 以用的。6
Re: [猶豫] 開始寫程式之後發現根本沒熱情我覺得,你現在能做的就是將工作變得有趣,讓你自己越來越喜歡這份 工作。這想法聽起來是騙人的,但就我經驗來說,確實是可能的。你想 想,同樣一份工作,一定有人覺得有趣,同時也有人覺得無趣。目前你 是覺得無趣的那類人,那麼該如何把它變得有趣,成為另一種人呢? 例如說,你發現你的工作就是一成不變——都在改程式碼。若是我,我1
Re: [問卦] 代問:如何寫出讓人看不懂的Python程式碼?ice 大請去看 Brainfuck / jsfuck。 python 的話,稍微 Google有 pyrhon-brianfuck 提供模組可引入。 然後盡可能背下來各區段之類的。 只要說:『博後應該要有閱讀程式的能力』之類的唬爛過去就好。 對於為何要這樣寫,就說:這是最佳化的結果,別的寫法可能到我畢業都還沒跑完。