arrayfire / arrayfire/arrayfire-python
[Question] [Feature Request] __matmul__, Internal Type Hinting
- 主要語言
- Python
- 星號
- 422
- 分支
- 63
- PR 合併指標
- 30 天內沒有已合併 PR
描述
I wanted to add support for @ operation in python. The \_\_matmult\_\_ operation, that's how it's overloaded, in the arrayfire.Array class.
It's a simple monkey patch on user code. But it'd be nice if it was official.
I went to my local source code and added it, but I wanted to start learning the internal more and maybe do some contribution. Just wondering if it's not redundant or unwanted.
I saw that the internal Python types aren't hinted properly.
The set_backend() takes a string, but that's primitive obsession. It should take a string litteral list.
from typing import Literal
backend: Literal["cuda", "opencl", "cpu"]
Or it should take an Enum.
And other functions.
or _clibrary_.get() returns a None. That's just due to Lazy Loading.
But a Typed Python interface could exist. Some wrapper python class might be needed so that the type of the exposed code is visible.
All of this would help learning by simply using the autocomplete features of the IDE or text editor.
I hope each backend offers at least some common interface. It should, as the goal of arrayfire is hardware agnostism.
So, every method should be discoverable by the linter at "code editing" time. Just put _ and __ if it's really private.
So get()._af_ wouldn't cause false linting errors.
Anyway, I might get into it if I have time. It seems like a nice contribution, and a nitpick of mine.
the typing package nd TYPE/CHECKING, and simple wrappers are quite powerful.
However, I know that you might not want to expose internal details at all, and so might have purposly not the type hinting of everything. But it's also possible that doing so is just a tedious boilerplate. I'd be fine with doing said tedious boilerplate to make it easier to use and understand.
So, if it's by choice that there isn't any type hinting and wrapper, then I won't do it. But If it's something you'd be interested in, I might do some work on it.
Also there was a bug with af.get_devicr_info(), it seems to give the default device, not active device. Tested it with my cpu graphics card and amd graphics card on arch linux. I'll edit this section once I'm back on my PC. (Away right now).
貢獻指南
這個儲存庫沒有索引到貢獻指南
研究方向
先檢視 arrayfire.Array、set_backend()、_clibrary_.get() 和 af.get_devicr_info() 周邊的 Python bindings,接著檢查現有公開方法是如何公開及測試的。在進行任何變更之前,釐清專案是否需要 __matmul__、執行時包裝器及靜態型別提示。對於選定的公開 API,當範圍已達成共識、型別定義一致且行為經過驗證時,即視為完成。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- python
- 領域
- api, developer-experience
- Issue 類型
- 功能
- 難度
- 5/5
- 預估耗時
- 一週以上
- 活躍度
- 停滯
- 描述清晰度
- 需要釐清
- 新手友好度
- 25/100