luxolus
/
pyo3
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #972 from PyO3/davidhewitt-patch-4 

Clarify wording in guide
This commit is contained in:
Yuji Kanagawa 2020-06-13 20:14:06 +09:00 committed by GitHub
parent f2f0ccd9e1 f58398d6e3
commit 090204c2b2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
guide/src/conversions.md
View File

@ -70,7 +70,7 @@ For most PyO3 usage the conversion cost is worth paying to get these benefits. A
When returning values from functions callable from Python, Python-native types (`&PyAny`, `&PyDict` etc.) can be used with zero cost. When returning values from functions callable from Python, Python-native types (`&PyAny`, `&PyDict` etc.) can be used with zero cost.
Because these types are references, in some situations the Rust compiler may ask for lifetime annotations. If this is the case, you should use `Py<PyAny>`, `Py<PyDict>` etc. instead - which are also zero-cost and can be created from the native types with an `.into()` conversion. Because these types are references, in some situations the Rust compiler may ask for lifetime annotations. If this is the case, you should use `Py<PyAny>`, `Py<PyDict>` etc. instead - which are also zero-cost. For all of these Python-native types `T`, `Py<T>` can be created from `T` with an `.into()` conversion.
If your function is fallible, it should return `PyResult<T>`, which will raise a `Python` exception if the `Err` variant is returned. If your function is fallible, it should return `PyResult<T>`, which will raise a `Python` exception if the `Err` variant is returned.