回答編集履歴
6
タイポ
answer
CHANGED
@@ -10,7 +10,7 @@
|
|
10
10
|
> PyAnyは、一旦try_into()によりPyObjectに変換した後extract()によりRustの型にキャストするようです。
|
11
11
|
|
12
12
|
そういう使い方は想定していません。
|
13
|
-
今回の例だと`&PyLIst`から`&PyAny`へアップキャスト(コスト
|
13
|
+
今回の例だと`&PyLIst`から`AsRef::as_ref`で`&PyAny`へアップキャスト(この操作は0コストです)して、 `&PyAny` から`FromPyObject::extract` でVecに変換しています。
|
14
14
|
基本的には`FromPyObject`でたいてい事足りると考えていいです。
|
15
15
|
ただこのへんの設計は今後大きく変わる可能性があり、0.7以降ではどうなるかわかりません(このアップキャストは無駄なので、改善が必要かなと思っています)。
|
16
16
|
|
5
さらに補足
answer
CHANGED
@@ -10,12 +10,13 @@
|
|
10
10
|
> PyAnyは、一旦try_into()によりPyObjectに変換した後extract()によりRustの型にキャストするようです。
|
11
11
|
|
12
12
|
そういう使い方は想定していません。
|
13
|
-
今回の例だと`&PyLIst`から`&PyAny`へアップキャスト(コスト0で常に可能、`as_ref`を使ってます)
|
13
|
+
今回の例だと`&PyLIst`から`&PyAny`へアップキャスト(コスト0で常に可能、`as_ref`を使ってます). `&PyAny` から`FromPyObject::extract` でVecに変換しています。
|
14
|
-
|
14
|
+
基本的には`FromPyObject`でたいてい事足りると考えていいです。
|
15
|
+
ただこのへんの設計は今後大きく変わる可能性があり、0.7以降ではどうなるかわかりません(このアップキャストは無駄なので、改善が必要かなと思っています)。
|
15
16
|
|
16
17
|
PyObjectはGILGuardとの接し方(?)がPyAny等と異なる型です。
|
17
18
|
たしかドキュメントに`PyObject::extract`を使え的な記述があったかと思いますが、これはrust-cpython時代から更新されていない記述です(直そうとは、思ってたんですけど)。
|
18
|
-
PyObjectを経由すると、少しオーバーヘッドになるので、あまり良くないです。
|
19
|
+
`&Py~`を持っているときにPyObjectを経由してなにかしようとすると、少しオーバーヘッドになるので、あまり良くないです。
|
19
20
|
|
20
21
|
(補足)
|
21
22
|
```rust
|
4
補足
answer
CHANGED
@@ -1,6 +1,6 @@
|
|
1
1
|
```rust
|
2
2
|
use pyo3::FromPyObject;
|
3
|
-
let
|
3
|
+
let v: Vec<usize> = dummy.as_ref().extract().unwrap();
|
4
4
|
```
|
5
5
|
これでできませんか?
|
6
6
|
|
@@ -15,4 +15,11 @@
|
|
15
15
|
|
16
16
|
PyObjectはGILGuardとの接し方(?)がPyAny等と異なる型です。
|
17
17
|
たしかドキュメントに`PyObject::extract`を使え的な記述があったかと思いますが、これはrust-cpython時代から更新されていない記述です(直そうとは、思ってたんですけど)。
|
18
|
-
PyObjectを経由すると、少しオーバーヘッドになるので、あまり良くないです。
|
18
|
+
PyObjectを経由すると、少しオーバーヘッドになるので、あまり良くないです。
|
19
|
+
|
20
|
+
(補足)
|
21
|
+
```rust
|
22
|
+
use pyo3::ObjectProtocol;
|
23
|
+
let v: Vec<usize> = dummy.extract().unwrap();
|
24
|
+
```
|
25
|
+
これもできます
|
3
誤った記述を修正
answer
CHANGED
@@ -1,6 +1,6 @@
|
|
1
1
|
```rust
|
2
2
|
use pyo3::FromPyObject;
|
3
|
-
let
|
3
|
+
let v2: Vec<usize> = dummy.as_ref().extract().unwrap();
|
4
4
|
```
|
5
5
|
これでできませんか?
|
6
6
|
|
@@ -10,8 +10,9 @@
|
|
10
10
|
> PyAnyは、一旦try_into()によりPyObjectに変換した後extract()によりRustの型にキャストするようです。
|
11
11
|
|
12
12
|
そういう使い方は想定していません。
|
13
|
-
&PyAny
|
13
|
+
今回の例だと`&PyLIst`から`&PyAny`へアップキャスト(コスト0で常に可能、`as_ref`を使ってます)->`impl FromPyObject for Vec` でVecに変換という感じですね。
|
14
|
-
|
14
|
+
あまりこのへんのインターフェースは洗練されていなくて、もう少し一貫性が欲しいところですが。
|
15
|
+
|
15
16
|
PyObjectはGILGuardとの接し方(?)がPyAny等と異なる型です。
|
16
17
|
たしかドキュメントに`PyObject::extract`を使え的な記述があったかと思いますが、これはrust-cpython時代から更新されていない記述です(直そうとは、思ってたんですけど)。
|
17
18
|
PyObjectを経由すると、少しオーバーヘッドになるので、あまり良くないです。
|
2
古いドキュメントについて加筆
answer
CHANGED
@@ -12,4 +12,6 @@
|
|
12
12
|
そういう使い方は想定していません。
|
13
13
|
&PyAny -> &PyListなどビルトイン型へのdowncast -> Rustの型へ変換
|
14
14
|
というのが基本の流れ(?)になります。
|
15
|
-
PyObjectはGILGuardとの接し方(?)がPyAny等と異なる型で
|
15
|
+
PyObjectはGILGuardとの接し方(?)がPyAny等と異なる型です。
|
16
|
+
たしかドキュメントに`PyObject::extract`を使え的な記述があったかと思いますが、これはrust-cpython時代から更新されていない記述です(直そうとは、思ってたんですけど)。
|
17
|
+
PyObjectを経由すると、少しオーバーヘッドになるので、あまり良くないです。
|
1
他の方の回答についてコメント
answer
CHANGED
@@ -4,4 +4,12 @@
|
|
4
4
|
```
|
5
5
|
これでできませんか?
|
6
6
|
|
7
|
-
また、英語に抵抗がないようでしたら、質問には https://gitter.im/PyO3/Lobby を使うのがいいと思います。
|
7
|
+
また、英語に抵抗がないようでしたら、質問には https://gitter.im/PyO3/Lobby を使うのがいいと思います。
|
8
|
+
|
9
|
+
(他の方の回答について)
|
10
|
+
> PyAnyは、一旦try_into()によりPyObjectに変換した後extract()によりRustの型にキャストするようです。
|
11
|
+
|
12
|
+
そういう使い方は想定していません。
|
13
|
+
&PyAny -> &PyListなどビルトイン型へのdowncast -> Rustの型へ変換
|
14
|
+
というのが基本の流れ(?)になります。
|
15
|
+
PyObjectはGILGuardとの接し方(?)がPyAny等と異なる型で、こういう場面では存在を意識しないほうがよいです(このへんは、歴史的事情により面倒な設計になっています)。
|