sapling/eden/scm/lib/cpython-async/Cargo.toml

20 lines
414 B
TOML
Raw Normal View History

[package]
name = "cpython-async"
version = "0.1.0"
edition = "2018"
[dependencies]
anyhow = "1"
async-runtime = { path = "../async-runtime" }
cpython-ext = { path = "../cpython-ext", default-features = false }
futures = "0.3"
cpython-async: drop py_stream_class macro Summary: The py_stream_class causes the code to be more verbose. It basically enforces the bindings crate to define new types wrapping pure Rust types, and then define py_stream_class. In a future diff, I'm adding FromPyObject/ToPyObject support for types that implements serde Deserialize/Serialize. py_stream_class gets in the way, because the blanket type from cpython-ext cannot be used in the py_stream_class macro. cpython-ext is not the proper place to define business-related stream types. Therefore, define a type-erased Python class, and implement FromPyObject/ToPyObject automatically for TStream<anyhow::Result<T>> where T implements FromPyObject or ToPyObject. The FromPyObject now converts a Python iterator back to a stream. It's no longer zero-cost. However, I'd imagine such usecases can be short-cut using pure Rust code. Background: Initially, I added some FromPyObject/ToPyObject impls to pure Rust crates gated by a "pytypes" feature. While that works fine with cargo build, buck does not support dynamic features and the fact that we support both py2 and py3 makes it extremely hard to support cleanly in buck build. For example, if minibytes::Bytes defines ToPyObject for Bytes, then any crate using minibytes would have 2 different versions: a py2 version, a py3 version, and they both depend on python. That seems to be a bad approach. Reviewed By: sfilipco Differential Revision: D23966984 fbshipit-source-id: eafb31ad458dcbdd8e970d8e419a10fbbe30595f
2020-10-03 07:50:08 +03:00
itertools = "0.8"
[dev-dependencies]
tokio = { version = "1", features = ["full"] }
[features]
default = ["python3"]
python2 = ["cpython-ext/python2"]
python3 = ["cpython-ext/python3"]