👋

I have been wanting to create some sort of tracing wrapper/library w/ pyo3 for some time (as I don't like python's logging lib) and would be down to team up on that if you are interested! I think more than anything it requires some discussion/thought/design.

I don't think at this point logging is a priority for me. I dug into tracing a little bit last week while reading up on #105 (see #122 ) but I learned of another approach that's simpler to implement. Tracing seems non-trivial to implement bindings for.

PS: I’ve been working on wrapping/shimming the reqwest library (which you can find here)

First, that looks like an absolutely massive API surface you're shooting for. I can't imagine that would be easy to maintain, and I imagine discoverability would be hard for end users, too, to know which Python modules are stable enough to depend on.

I arrived at a similar method for wrapping and handling a response body (using a bytes wrapper type and IntoPyObject)

In obstore we don't always materialize a response body into a single buffer. We hold a generic response type and then support async or sync iteration over the stream of chunks, or you can materialize it into one chunk.

I see in ryo3-bytes you have a tiny shim around Bytes, but you don't implement conversions from Python. And you only support copying memory between Rust and Python, while here we support zero-copy conversions via the buffer protocol.

Are you planning to publish the pyo3-bytes crate?

It is published: https://docs.rs/pyo3-bytes/latest/pyo3_bytes/

would love to collaborate on some pyo3 projects.

I'm always open to contributions! Obstore is getting ready for an 0.3 release, but if you're interested there are some other issues you could tackle, for example #89

Add logging #93

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions