[Bug]: PEP 688 `__buffer__` missing on builtin types
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 68/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 静か
- 領域
- backend, testing-qa
調査の方向性
PBytesLike.java と管理対象型の初期化パスから始め、参照されている CPython の test_buffer.py のケースを unittest_tags/test_buffer.txt と比較します。組み込み型の辞書とバッファーアクセスがどのように公開されているかを、issue で名前が挙げられている ObjectBuiltins.java と TypeBuiltins.java のパスを含めて追跡します。タグ付きテストが成功し、一覧にある組み込みバッファー型が CPython と同じ dunder を公開すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Describe the bug
GraalPy registers no __buffer__ or __release_buffer__ on its managed types. So dir(b"") returns 77 names where CPython 3.12 returns 78, bytearray().__buffer__(0) raises AttributeError, and isinstance(b"", collections.abc.Buffer) is False. The buffer protocol itself works; only the PEP 688 Python-level dunders are missing.
Operating system
Linux
CPU architecture
ARM64
GraalPy version
25.2.4 (Python 3.12.8); also reproduced on 25.0.2
JDK version
No response
Context configuration
No response
Steps to reproduce
import collections.abc
print(len(dir(b"")), "__buffer__" in dir(b""))
print(isinstance(b"", collections.abc.Buffer))
bytearray(b"hello").__buffer__(0)
GraalPy 25.2.4:
77 False
False
Traceback (most recent call last):
File "/tmp/buf.py", line 5, in <module>
bytearray(b"hello").__buffer__(0)
AttributeError: 'bytearray' object has no attribute '__buffer__'
Expected behavior
CPython 3.12.13 raises nothing, and __buffer__(0) returns a memoryview:
78 True
True
Stack trace
Additional context
Every builtin buffer type is affected, not just bytes. "__buffer__" in dir(t) / "__release_buffer__" in dir(t):
| type | GraalPy 25.2.4 | CPython 3.12.13 |
|---|---|---|
bytes |
False / False | True / False |
bytearray |
False / False | True / True |
memoryview |
False / False | True / True |
array.array |
False / False | True / True |
mmap.mmap |
False / False | True / True |
CPython's test_buffer.TestPythonBufferProtocol.test_call_builtins covers this case, calling both dunders on a bytearray (test_buffer.py#L4589-L4595). It is missing from unittest_tags/test_buffer.txt, which tags only the four cases built on user-defined classes, so CI never sees the gap.
Root Cause
Nothing in the Java core registers the dunder: git grep __buffer__ -- graalpython/com.oracle.graal.python/src returns no hits at 730597a0. bytes.__dict__ has no entry for it, and dir() only merges the MRO type dicts (ObjectBuiltins.java#L869 into TypeBuiltins.java#L1240), so it reports 77.
CPython synthesizes the wrapper in add_operators, which PyType_Ready calls to walk slotdefs and add a descriptor to tp_dict for every slot a type defines. The two slots are declared at Objects/typeobject.c#L9501-L9506, and bytes gets bf_getbuffer from bytes_as_buffer, installed as tp_as_buffer at #L2969:
static PyBufferProcs bytes_as_buffer = {
(getbufferproc)bytes_buffer_getbuffer,
NULL,
};
bf_releasebuffer is NULL there, so __release_buffer__ is not added. That is why the dir() difference is exactly one name.
The protocol underneath is already there: PBytesLike exports PythonBufferAccessLibrary (PBytesLike.java#L62-L64) and memoryview(b"ab") works. The C extension layer carries the same BUFSLOT definitions (cext/src/typeobject.c#L10461-L10466), but only for native types. Managed builtin types are the gap.
See PEP 688 and object.__buffer__.
Fix Suggestion
Each managed buffer type needs __buffer__, and __release_buffer__ only where the CPython counterpart defines bf_releasebuffer. bytes takes the first alone, the other four take both. Registering the dunders as builtins per type and synthesizing them at type initialization for every type exporting PythonBufferAccessLibrary, the way add_operators walks slotdefs, both seem workable; exporting that library does not by itself separate the two groups above, so which approach fits GraalPy's type setup is better judged by the maintainers.
- 主要言語
- Python
- スター
- 1.7k
- フォーク
- 155
- 平均マージ
- 7時間 16分
- マージ済み PR(30日)
- 51
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
oracle/graalpython のほかの issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
oracle/graalpython#1105 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
oracle/graalpython#1102 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 74/100
oracle/graalpython#1133 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
oracle/graalpython#1112 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
oracle/graalpython#1111 ·
メンテナーはふだん 1 日以内に返信
oracle/graalpython の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
FuRongJun-1999/dsh-memory#56 ·
メンテナーはふだん 1 日以内に返信
-
Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
pgadmin-org/pgadmin4#10503 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
521xueweihan/HelloGitHub#3857 ·
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
rai-opensource/spatialmath-python#235 ·
メンテナーはふだん 1 日以内に返信
-
needs-ac
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
Ikalus1988/MisakaNet#2845 ·
メンテナーはふだん 1 日以内に返信