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

Some comments on interchange API from an Arrow developer

オープン
  • 何か問題がありますか？
#61 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
numpy, pandas, python
領域
api, data

調査の方向性

この issue は Column docstring、その null_count property、および dtype docstring を指している。まずこれらのセクションと現在の interchange proposal を読むこと。API ドキュメントまたは design で、Arrow C interface wording、mask and null semantics、variable-size strings、conversions、および nested-data scope を解決すること。未解決の問題について明確な決定と更新された guidance が示されれば完了とする。

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

説明

interchange-protocol

hi all, great to see some continued work on this project after the original discussion from last year. I still think it's useful to allow libraries to "throw data over the wall" without forcing eager serialization to a particular format (like pandas or Arrow)

From Column docstring:
    TBD: Arrow has a separate "null" dtype, and has no separate mask concept.
         Instead, it seems to use "children" for both columns with a bit mask,
         and for nested dtypes. Unclear whether this is elegant or confusing.
         This design requires checking the null representation explicitly.

Could you clarify what is confusing? I do not understand the statement 'Instead, it seems to use "children" for both columns with a bit and for nested dtypes.'

Later

         The Arrow design requires checking:
         1. the ARROW_FLAG_NULLABLE (for sentinel values)
         2. if a column has two children, combined with one of those children
            having a null dtype.

         Making the mask concept explicit seems useful. One null dtype would
         not be enough to cover both bit and byte masks, so that would mean
         even more checking if we did it the Arrow way.

You mean the Arrow C interface here. Could you clarify what these other things mean?

  • If ARROW_FLAG_NULLABLE is set, then the first buffer (the validity bitmap) governs nullness.
  • The 2nd item here "if a column has two children, combined with one of those children having a null dtype." does not make sense to me, because nulls in Arrow are exclusively determined by the validity bitmap. Arrow does have a "Null" type, but this represents data whose values are always all null and has no associated buffers.

Re: "One null dtype would not be enough to cover both bit and byte masks, so that would even more checking if we did it the Arrow way.", I don't know what this means, could you clarify?

Column methods
    @property
    def null_count(self) -> Optional[int]:
        """
        Number of null elements, if known.
        Note: Arrow uses -1 to indicate "unknown", but None seems cleaner.
        """
        pass

Here you should indicate that you mean that the Arrow C interface (where the null_count is an int64)

General comments / questions
  • It feels a little unfortunate to go "halfway to Arrow" with adding the string offsets buffer, requiring serialization always for variable-size binary data. I haven't thought through what would be alternatives for string data that do not necessarily force this serialization (similar to the API proposal from https://github.com/wesm/dataframe-protocol/pull/1) — if the goal of this API is to reduce the need to serialize, having some alternative here might be worthwhile
  • It seems like it would be useful to provide some to_* methods on Column (like Column.to_arrow) — I guess that pyarrow could implement a built-in implementation of this interface, but some producers might be able to produce Arrow or NumPy arrays directly and skip the lower-level memory export that's provided here.
  • Is there interest in supporting nested / non-flat data in this interchange API? I notice that they are explicitly excluded from the dtype docstring, but I would encourage you to think about them up front rather than bolting on later.
主要言語
Python
スター
106
フォーク
22
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

data-apis/dataframe-api のほかの issue

data-apis/dataframe-api の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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