1樓：Ivony
上下文關鍵字嘛，沒什麼特別的。
C#從第乙個版本就支援上下文關鍵字，get和set。
然後從第乙個版本就沒有再增加過任何乙個非上下文關鍵字，算是把上下文關鍵字用到極致了……
那麼乙個語言可不可以沒有任何關鍵字，全部都是上下文關鍵字和可過載的運算子呢？
理論上是可以的，但是實際上這種語言會非常難用……另外，這也叫做神仙語句？
public
static
async
Task
>Async ()public static async async ()你猜猜哪些async和await是上下文關鍵字？哪些不是？ 然後更神奇的是，VisualStudio竟然可以正確的進行語法著色……（當然紙糊的這個你就別指望了） 2樓：向陽 一些語言（例如題主問的）會存在一類特殊的關鍵字，它僅在特定上下文有效。這類關鍵字被描述為「Identifiers with special meaning」，字面意思，具有特殊意義的識別符號。 除了題主所舉的python例子外，例如C++裡面的final、override也是這樣的情況 在實現上面也不複雜，例如手擼的遞迴下降，讓parser調lex的時候測試一下返回值結果即可實現 3樓： 人能理解的語法規則, 都是可以做成語法分析器的, 只不過是實現難度的區別. 同樣, 可以做到讓一些詞在特定上下文中才是關鍵字. 只不過這些對 parser (語法分析器) 提出了更高的要求. 而在 Python3.9 中就引入了新的 parser, 解決了技術上的困難. PEP 617 -- New PEG parser for CPython 4樓：銀河-蝸牛 我最早也有同樣的擔心，但答案是不會，python3.10 的模式匹配語法是完全向後相容的，這正是它的神奇之處。得益於 python3. 9 中改進的新的 PEG 語法解析器，python 能夠支援更加複雜的語法，這裡就是一例：軟關鍵字。簡單地說，就是語法解析器能夠識別，在應該當做關鍵字的地方，match 被識別為關鍵字，而在應該作為識別符號的地方，match 就是合法的識別符號，比如 re. match。case、甚至還有單下劃線 「_」，同理也是軟關鍵字。 但是，這樣的改進很大程度得益於 PEG 解析器，它是乙個解析器，需要解析語法。而一些語法高亮的程式通常並不解析語法，而只是進行詞法分析，對於它們來說如何識別 match 這樣的軟關鍵字就成為了乙個難題。比如語法高亮庫 pygments 至今還不支援這些軟關鍵字。 可以這麼理解，Python是語言的操作介面。C語言等為了各種原因 主要是效能 有諸多對程式設計師不太不友好的性質，比如嚴格型別，函式沒有字面量，這些性質在編寫如作業系統，資料庫時是有益甚至必須的。Python則能讓程式設計師更多的思考演算法本身，比如資料庫或檔案的底層操作一般是C或C 寫的，使用Py... lbaby 我能知道的就只有列表生成吧 其他的像re,yield，協程，裝飾器,lame lambda和函式特性，列表迭代，別的語言也有。吐槽一句，一直不喜歡Python太囉嗦，還各種exception. 下面主要是站在乙個C 使用者角度而言，很好用的一些特性 函式式程式設計的幾個map,reduc... 不知道為啥這麼多人反對。雖然。有些複雜不直觀。而且功能不強大，還完全可以通過其他方式代替，同時其他方式的實現還可以完成更多的功能。但是至少這種方法寫起來稍微。短那麼一些。 原子筆 C 標準委員會，只需引入乙個別的指令碼語言，放預處理後編譯期前去解釋執行，就可以簡單解決這些各種問題 巨集的功能太弱，但...如何使用Python的膠水語言特性？
Python 的哪些特性或用法讓你相見恨晚？
如何評價C 17中的新特性fold expression？