[3.13] copyreg._reconstructor failures for protocol 0 and 1 for `dateutil.tz.tzutc`
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
Bug description:
In [25]: pickle.load(open('taskwarrior/f91b9e98-7586-4317-ae52-b516e97209e5', 'rb'))
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
Cell In[25], line 1
----> 1 pickle.load(open('taskwarrior/f91b9e98-7586-4317-ae52-b516e97209e5', 'rb'))
File /usr/lib/python3.13/copyreg.py:44, in _reconstructor(cls, base, state)
41 def _reconstructor(cls, base, state):
42 if base is object:
43 #obj = cls.__new__(cls)
---> 44 obj = object.__new__(cls)
45 else:
46 obj = base.__new__(cls, state)
TypeError: object.__new__(tzutc) is not safe, use tzutc.__new__()
It seems that cls.__new__(cls) is the correct way to achieve the desired effect for any type of object?
This issue was not present in 3.12, or at least same code on same pickles used to work.
I was not able to reproduce this with arbitrary data serialization/deserialization (e.g. pickle.dump(tzutc(), f); pickle.load(f) works), which suggests this is dependent on how exactly data is structured, and so I'm including the culprit pickle here: 74b9da0a-ab54-437f-9ab5-549e886d3c83.txt
CPython versions tested on:
3.13
Operating systems tested on:
Linux
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
copyreg.py の44行目付近から始め、dateutil.tz.tzutc を使って Python 3.13 で添付された pickle の失敗を再現します。Python 3.12 とプロトコル 0 および 1 の動作を比較し、その後、選択した変更によって動作しているケースが維持され、提供された pickle が正しく読み込まれることを確認します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- backend
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 42/100