teratail header banner
teratail header banner
質問するログイン新規登録

回答編集履歴

6

タイポ

2019/04/05 14:34

投稿

kngwyu
kngwyu

スコア48

answer CHANGED
@@ -10,7 +10,7 @@
10
10
  > PyAnyは、一旦try_into()によりPyObjectに変換した後extract()によりRustの型にキャストするようです。
11
11
 
12
12
  そういう使い方は想定していません。
13
- 今回の例だと`&PyLIst`から`&PyAny`へアップキャスト(コスト0常に可能、`as_ref`を使ってます). `&PyAny` から`FromPyObject::extract` でVecに変換しています。
13
+ 今回の例だと`&PyLIst`から`AsRef::as_ref`で`&PyAny`へアップキャスト(この操作は0コストです)して、 `&PyAny` から`FromPyObject::extract` でVecに変換しています。
14
14
  基本的には`FromPyObject`でたいてい事足りると考えていいです。
15
15
  ただこのへんの設計は今後大きく変わる可能性があり、0.7以降ではどうなるかわかりません(このアップキャストは無駄なので、改善が必要かなと思っています)。
16
16
 

5

さらに補足

2019/04/05 14:34

投稿

kngwyu
kngwyu

スコア48

answer CHANGED
@@ -10,12 +10,13 @@
10
10
  > PyAnyは、一旦try_into()によりPyObjectに変換した後extract()によりRustの型にキャストするようです。
11
11
 
12
12
  そういう使い方は想定していません。
13
- 今回の例だと`&PyLIst`から`&PyAny`へアップキャスト(コスト0で常に可能、`as_ref`を使ってます)->`impl FromPyObject for Vec` でVecに変換う感じで
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

補足

2019/04/05 14:33

投稿

kngwyu
kngwyu

スコア48

answer CHANGED
@@ -1,6 +1,6 @@
1
1
  ```rust
2
2
  use pyo3::FromPyObject;
3
- let v2: Vec<usize> = dummy.as_ref().extract().unwrap();
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

誤った記述を修正

2019/04/05 14:24

投稿

kngwyu
kngwyu

スコア48

answer CHANGED
@@ -1,6 +1,6 @@
1
1
  ```rust
2
2
  use pyo3::FromPyObject;
3
- let v: Vec<usize> = dummy.extract().unwrap();
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 -> &PyListなどビルトイン型へのdowncast -> Rustの型へ変換
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

古いドキュメントについて加筆

2019/04/05 13:06

投稿

kngwyu
kngwyu

スコア48

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

他の方の回答についてコメント

2019/04/05 12:46

投稿

kngwyu
kngwyu

スコア48

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等と異なる型で、こういう場面では存在を意識しないほうがよいです(このへんは、歴史的事情により面倒な設計になっています)。