Conversation
These imports are written in a small DSL like:
```rust
#[pymodule(stubs = {
from datetime import datetime as dt, time;
from uuid import UUID;
})]
```
Then parsed, sent as an AST inside the introspection data (following the same AST format as the type hints) and serialized by the introspection crate that merges these imports with the auto generated ones
The `#[pymodule]` parameter is named `stub` because we might include some other features in the future like protocols
davidhewitt
left a comment
davidhewitt
left a comment
There was a problem hiding this comment.
Thanks, I have a feeling it'll take a couple of rounds of review to figure out my preferred design on this one! Please bear with me 🙏
| from datetime import datetime as dt, time; | ||
| from uuid import UUID; |
There was a problem hiding this comment.
I can't decide how I feel about having full Python syntax embedded within the rust source like this. What are the alternatives? e.g. could be text, then it would be possible to use include_str! to maintain the stub as external Python file. That would also avoid the limitations of formatting & Rust syntax.
Possibly also interesting is https://github.com/m-ou-se/inline-python
There was a problem hiding this comment.
I see two advantages of the current design:
- having the imports close to the code (including the custom type annotation) makes it easier to get a single source of truth
- having it parsed by a macro means we validate the syntax and send it to
pyo3-introspectionas an AST. This makes quite easy for the stub generation code to add to these custom imports the extra ones that are needed to for the type annotations generated by PyO3 and get a clean output.
I fear that skipping parsing step would make imports management quite painful and if we have to pay the parsing price, then it's nice to have such an embedding.
But I don't feel strongly on that, glad to pivot the MR toward something else if it's better.
if we go the embedding way, I am not sure about the ;
Pros:
- if we allow more and more Python syntax including top level expressions it is required if we want to keep being able to use
syn - it might make autoformatting possible
Cons:
- departs from Python and confusing for the users
| /// A Python statement | ||
| enum PyStatement { | ||
| ImportFrom(PyImportFrom), | ||
| Import(PyImport), | ||
| } |
There was a problem hiding this comment.
I'm curious why limit the stubs to just these statements - is that just to keep initial implementation scope under control?
There was a problem hiding this comment.
Yes! I guess we will expend this list to support things like protocol
2 participants
This feature is required to allow user-provided custom type hint to import types
These imports are written in a small DSL on the module like:
Then parsed, sent as an AST inside the introspection data (following the same AST format as the type hints) and serialized by the introspection crate that merges these imports with the auto generated ones
The
#[pymodule]parameter is namedstubbecause we might include some other features in the future like protocols