小結 python 實戰中遇到的幾種需要化名的情境

2021-09-28 16:59:09 字數 3390 閱讀 2363

笑來在《自學是門手藝》的《2.4.3 化名與匿名》中,講到了函式的化名。經過幾個月的實戰,我發現,實際上化名無處不在。我有時也會稱之為「別稱」,意思一樣。函式化名只是化名的一種應用場景,還有好幾種使用化名的地方,本篇筆記將整理小結我所遇到的各種化名。

匯入其它模組時,直接化名為簡約版,是我相當常用的,甚至有一些業界約定俗成的化名。無論是模組,模組中的函式或變數,都可以此種方式化名簡化之。

# 業界約定俗成的一些化名

import pandas as pd

import numpy as np

# 自定義模組與自定義函式的化名

from zhihu_base import get_all_topics_detail as zhihu

我程式設計時給函式或變數命名的習慣是,讓人一看到名字就能知道該它是做什麼的,如此以來名稱就會挺長。函式因為要被呼叫,尤其是外部呼叫,寫的複雜點倒能理解。但如果是乙個不被外部呼叫的變數,為什麼不直接在定義變數時就定義乙個簡約的名字呢?

這裡有一種情境,呼叫該變數的大部分語句都相對簡約,用全稱更易讀,但偶爾有一句複雜的語句,要多次呼叫該變數,導致該語句特別長,此時要臨時要用乙個變數化名,簡化**。

sql_search =

'select url_token,zhihu_name,lase_active_time from zhihu_whos_v;'

df_topics_details = pd.read_sql(sql_search,conn)

# 這裡省略很多**

# 此時出現一條相對複雜冗長的語句,多次出現該變數名

df_value_v = df_topics_details[

(df_topics_details[

'upvotecount'

]>

100000)&

(df_topics_details[

'last_activity'

]>

'2019-09-01'

)]

該語句是為了把 df_topics_details 這個資料集之中,符合條件upvotecount > 100000last_activity >'2019-09-01'的資料篩選出來,是pandas中相當常用的語句。後來我發現,在這種多次呼叫某個變數名或函式名的語句中,可以臨時加乙個化名,來簡化該語句長度。像這樣:

df_topics_details = dtd

df_value_v = dtd[

(dtd[

'upvotecount'

]>

100000)&

(dtd[

'last_activity'

]>

'2019-09-01'

)]

但是這種化名,並不適合在定義該變數時就如此做。試想我一開始就把該變數定義為dtd,其餘許多行**會極其不易讀——我或者**的其它讀者完全無法理解dtd指代什麼。如果更多變數都採用這種風格,**的可讀性將有多糟糕啊!

其實檔案物件化名這個說法倒不準確,本質上是變數的賦值:把乙個特定的檔案物件賦值給乙個變數來指代保管。單獨拎出來,是因為它太高頻使用了。類似fw或者frwriter也是約定俗成的命名習慣。

例項 x:

fw =

open

("my_test.txt"

,"at"

)fw.write(

"xue.cn 月收費僅15元,對程式設計自學者相當友好。"

)fw.close(

)

例項y:

with

open

("my_test.txt"

,"at"

)as fw:

fw.write(

)

例項z:

comms_file = output_path +

'xuecn_comments_statistics_'

+str

(datetime.datetime.now())

[:10]

+'.xlsx'

with pd.excelwriter(comms_file)

as writer:

comms_counts_monthly.to_excel(writer, sheet_name=

) comms_counts_weekly.to_excel(writer, sheet_name=

) comms_counts_daily.to_excel(writer, sheet_name=

) comms_by_reg_date.to_excel(writer, sheet_name=

) comms_by_reg_week.to_excel(writer, sheet_name=

) comms_counts_by_hour.to_excel(writer, sheet_name=

) vote_by_name.to_excel(writer, sheet_name=

'使用者獲讚'

) name_count_by_vote.to_excel(writer, sheet_name=

'使用者獲讚的分布'

) vote_by_content.to_excel(writer, sheet_name=

) content_count_by_vote.to_excel(writer, sheet_name=

)

with data as(

select

date(created_at) as time,

user_id

from user_comments

union all

select

date(created_at) as time,

user_id

from user_activities

)select

time,

count(distinct user_id) as 每日學習使用者數

from data

group by time

order by time

def who_is_v_detail

我比較少細究某個化名,到底是對函式、變數或物件進行化名。核心在於,化名只是給名字複雜的東西,另外取了乙個簡單好記的指代他,不管名字如何,那東西的特性不變,所指代的總還是ta。

好似某個人叫「因缺思廳·尼古拉斯·蔣·巴斯帝國五世·一品帶刀侍衛·阿拉斯加·狗蛋·王」,你可以簡稱他:老王。

vue實戰中遇到的 坑

也可能是因為接觸vue時間也不長,經常落入不知名的 坑 中,對於我這個菜鳥來說,每次 落坑 無疑是一場不小的災難。前兩天有個朋友在問我,在使用vue中有沒有遇到一些很難解決的問題,一下我也只能說出一兩個,正所謂 光說不練,假把式 所以索性就抽時間總結一下我在專案中遇到的vue的問題,也貼出了效果,這...

關於MogonDB在面試中可以會遇到的幾個問題

1 需求變化新繁 開發要更加敏建,開發成本和維護成本要更低,要能夠快速地更新進化,功能要在最短的周明內上線。2.客戶端 api支援,因為這直接影響開發效率 3.部署和使用簡單 4.擴充套件能力強 5.節省系統資源,對cpu等資源耗費較小 滿足這些要求的nosq 方率,就剩下了mongodb和redi...

python中的get dummies實戰

1 離散特徵的取值之間沒有大小的意義,比如color red,blue 那麼就使用one hot編碼 2 離散特徵的取值有大小的意義,比如size x,xl,xxl 那麼就使用數值的對映說明 對於有大小意義的離散特徵,直接使用對映就可以了,使用pandas可以很方便的對離散型特徵進行one hot編...