快取（弱字典）

需要維護代表外部狀態的物件，將單個例項對映到外部現實，其中允許多個例項對映到相同的外部資源會給維護例項間的同步帶來不必要的困難。在這些情況下，一種常見的慣用方法是支援例項快取；工廠函式用於返回新例項或現有例項。

這種方法的困難在於必須容忍兩種情況之一：要麼快取無限制地增長，要麼需要在應用程式的其他地方進行快取的顯式管理。後者可能非常繁瑣，並且會導致比實際解決當前問題所需的更多程式碼，而前者對於長時間執行的程序甚至記憶體需求較大的相對較短的程序來說是不可接受的。

• 無論內部使用者有多少，需要由單個例項表示的外部物件。這對於表示需要整體寫回磁碟而不是每次使用時鎖定和修改的檔案可能很有用。
• 建立成本高昂但可能被多個內部消費者需要的物件。類似於第一種情況，但不一定與外部資源繫結，並且可能不是共享狀態的問題。只有當存在某種“軟”引用或單個物件的使用者生命週期高度重疊時，弱引用才在這種情況下有用。

迴圈引用

• DOM需要大量的迴圈引用（到父節點和文件節點），但這些可以透過使用從每個節點到其父節點的弱字典對映來消除。這在諸如xml.dom.pulldom之類的上下文中可能特別有用，允許.unlink()操作變為無操作。

本提案分為以下幾節

• 提議的解決方案
• 實現策略
• 可能的應用
• Python中之前的弱引用工作
• Java中的弱引用

由於早期提案的全文似乎無法在網上找到，因此將其作為附錄包含在內。

失效

過去解決弱引用失效的方法通常依賴於儲存一個強引用，並能夠檢查弱引用物件的所有例項，並在其引用物件的引用計數變為一（表明弱引用儲存的引用是最後一個剩餘引用）時使它們失效。這樣做的好處是Python的記憶體管理機制無需改變，並且任何型別都可以被弱引用。

這種失效方法的缺點是它假設弱引用的管理被足夠頻繁地呼叫，以便在相當短的時間內發現弱引用物件；由於這意味著掃描某個資料結構以使引用失效，這是一個O(N)的操作（N是弱引用物件的數量），因此對於任何單個弱引用物件而言，這種操作並不能有效地分攤成本。這還假設應用程式以某種頻率呼叫處理弱引用物件的程式碼，這使得弱引用對庫程式碼的吸引力降低。

另一種失效方法是讓解除分配程式碼意識到弱引用的可能性，並在每次物件解除分配時專門呼叫弱引用管理程式碼來處理失效。這要求更改可弱引用物件的tp_dealloc處理程式；對於支援弱引用的物件，需要在處理程式的“頂部”進行額外的呼叫，並且還需要一種將物件對映到該物件的弱引用鏈的有效方法。

呈現方式

弱引用向Python層呈現的兩種方式是：作為顯式引用物件，需要對其執行某些操作才能檢索對底層物件的可用引用；以及作為儘可能偽裝成原始物件的代理物件。

當在Python中新增額外的物件管理層時，引用物件很容易使用；可以顯式檢查引用的活躍性，而無需在引用物件上呼叫操作並捕獲在使用無效弱引用時引發的特殊異常。

然而，許多使用者偏愛代理方法，僅僅因為弱引用看起來非常像原始物件。

提案：虛擬引用

為了部分解決關於引用計數與垃圾回收的反覆討論，我提議對 Python 進行擴充套件，這應該有助於建立“結構良好”的迴圈圖。特別是，它應該允許至少建立帶有父後向指標的樹和雙向連結串列，而無需擔心迴圈。

我提議的基本機制是“虛擬引用”，或簡稱“vref”。vref 本質上是對一個物件的控制代碼，它不增加物件的引用計數。這意味著持有對一個物件的 vref 不會阻止該物件被銷燬。例如，這將允許 Python 程式設計師建立上述樹結構，當它不再使用時會自動銷燬——透過將所有父後向引用轉換為 vref，它們不再建立阻止樹銷燬的引用迴圈。

為了實現這種機制，Python 核心必須確保永遠不會留下任何實際的指標引用不再存在的物件。我提出的實現涉及對當前 Python 系統的兩個基本補充

1. 一種新的“vref”型別，Python 程式設計師透過它建立和操作虛擬引用。在內部，它基本上是一個 C 級 Python 物件，帶有一個指向它所引用的 Python 物件的指標。然而，與所有其他 Python 程式碼不同，它不改變此物件的引用計數。此外，它包括兩個指標來實現雙向連結串列，下面將用到這個連結串列。
2. 在基本 Python 物件中新增一個新欄位（PyObject_Head 在 object.h 中），該欄位要麼是 NULL，要麼指向所有引用它的 vref 物件列表的頭部。當一個 vref 物件將自身附加到另一個物件時，它會將自身新增到此連結串列中。然後，如果一個帶有任何 vref 的物件被解除分配，它可以遍歷此列表並確保其上所有 vref 都指向某個安全值，例如 Nothing。

這種實現有望對當前 Python 核心產生最小的影響——當不存在 vref 時，它應該只為所有物件新增一個指標，並在每次物件解除分配時檢查一個 NULL 指標。

回到 Python 語言層面，我考慮了 vref 物件的兩種可能的語義——

指標語義

在此模型中，vref 本質上表現得像一個 Python 級別的指標；Python 程式必須顯式地解引用 vref 才能操作它實際引用的物件。

使用此模型的一個 vref 模組示例可以包含函式“new”；當用作“MyVref = vref.new(MyObject)”時，它返回一個新的 vref 物件，使得 MyVref.object == MyObject。MyVref.object 然後會在 MyObject 被解除分配時變為 Nothing。

舉一個具體的例子，我們可以引入一些新的C風格語法

• & – 一元運算子，建立物件的vref，與 vref.new() 相同。
• * – 一元運算子，解引用vref，與 VrefObject.object 相同。

然後我們可以定義

1.     type(&MyObject) == vref.VrefType
2.        *(&MyObject) == MyObject
3. (*(&MyObject)).attr == MyObject.attr
4.          &&MyObject == Nothing
5.           *MyObject -> exception

規則 #4 很微妙，但它的產生是因為我們建立了一個指向（沒有實際引用的 vref）的 vref。因此，當內部 vref 不可避免地消失時，外部 vref 會被清除為 Nothing。

代理語義

在這個模型中，Python 程式設計師操作 vref 物件，就像她在操作它所引用的物件一樣。這是透過實現 vref 來實現的，使得對其進行的所有操作都被重定向到其引用的物件。在這個模型中，解引用運算子 (*) 不再有意義；相反，我們只有引用運算子 (&)，並定義

1.  type(&MyObject) == type(MyObject)
2.        &MyObject == MyObject
3. (&MyObject).attr == MyObject.attr
4.       &&MyObject == MyObject

同樣，規則 #4 很重要——在這裡，外部 vref 實際上是對原始物件的引用，而不是內部 vref。這是因為對 vref 應用的所有操作實際上都應用於其物件，因此建立 vref 的 vref 實際上會導致建立後者物件的 vref。

第一種，指標語義，其優點是非常容易實現；vref 型別極其簡單，最少只需要一個屬性 object 和一個建立引用的函式。

然而，我真的很喜歡代理語義。它不僅減輕了 Python 程式設計師的負擔，而且還允許你做一些很棒的事情，比如在任何使用實際物件的地方使用 vref。不幸的是，在當前的 Python 實現中實現它可能會非常痛苦，甚至幾乎不可能。不過，如果這看起來很有趣，我確實有一些想法，其中一種可能性是引入新的型別檢查函式來處理 vref。這有望使不期望 vref 的舊 C 模組簡單地返回型別錯誤，直到它們可以修復。

最後，這個系統還可以提供一些其他功能。其中一個對我來說特別有趣的功能是允許 Python 程式設計師向 vref 新增“解構函式”——這個 Python 函式將在被引用物件被解除分配之前立即呼叫，允許 Python 程式不可見地將自身附加到另一個物件並監視它消失。這看起來很棒，儘管我還沒有想出任何實際用途…… :)

——Dianne