Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Bug]: PEP 688 `__buffer__` missing on builtin types

オープン
#1,072 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
java, python

調査の方向性

PBytesLike.java と管理対象型の初期化パスから始め、参照されている CPython の test_buffer.py のケースを unittest_tags/test_buffer.txt と比較します。組み込み型の辞書とバッファーアクセスがどのように公開されているかを、issue で名前が挙げられている ObjectBuiltins.java と TypeBuiltins.java のパスを含めて追跡します。タグ付きテストが成功し、一覧にある組み込みバッファー型が CPython と同じ dunder を公開すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

bug
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

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

oracle/graalpython のほかの issue

oracle/graalpython の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。