toolz.thread_first（）和toolz.thread_last（）的用途是什麼？

Question

見toolz.thread_first()和toolz.thread_last()。

在我看來，他們使代碼嚴重劣質。考慮

x = f(x) 
x = g(x) 
x = h(x) 

與

x = thread_last(x, 
       f, 
       g, 
       h) 

第一個例子是

1. 更可讀的和容易理解，
2. 上的外部Python庫不依賴，
3. 容易調試，因爲多條語句各有自己的一行，並且
4. 更詳細，但不是顯着的保證金。

即使你想通過，比方說通過x，功能的可變大小的列表與x = thread_first(x, *funcs)，這可能僅僅是定期迭代完成 - 這是再次，更詳細的，但它不喜歡這個無論如何，情況都會出現。

爲什麼會有人想要使用thread_first()和thread_last()？對我來說，它基本上看起來非常糟糕。 原則上，實現一種通過函數管理參數列表的方式可能會導致通過並行化加速 - 但在我看來並不像這些實現實際發生的那樣。

Answer 1

雖然這主要是基於輿論有很多好處：

命名的東西是很難（或者所以他們說）thread_*或pipe允許您跳過中間的分配。無需發明幾十個中間名，甚至更糟糕的生活在地獄的變數x,y,z變數。

專注於數據流和數據結構使清潔的聲明風格。大部分代碼可以表示爲簡單的數據結構，並使用標準數據結構方法進行轉換。可以說，它使你的代碼更容易理解：

thread_first(
    url, 
    requests.get, 
    requests.models.Response.json, 
    operator.itemgetter("result")) 

和撰寫/重用代碼：

request_pipeline = [authorize, fetch, validate] 
api_response = [render_json] 
html_response = [render_html] 

thread_first(request, *request_pipeline + api_response) 
thread_first(request, *request_pipeline + html_response) 

焦點轉移到引用透明它自然強制小，引用透明的功能和副作用（雙關意圖）使您的代碼更容易調試。

它起着非常好，懶惰代碼（toolz.map，toolz.filter）這使得它非常適合數據處理上，可能是無限的，數據結構。

最後你要記住，這些功能不是單獨存在的。它們旨在與toolz（尤其是功能組合和咖喱）的其他部分一起使用，內置模塊（如operator）和第三方工具（如multipledispatch）非常好用。只有這樣他們才能發揮出全部力量。在toolz實施

然而很多想法進來嚴格的函數式語言（Clojure的和藥劑）是更加自然的和你所提到的，可能感覺不到自然的Python開發。