-
-
Couldn't load subscription status.
- Fork 0
refactor: move python public API to djc-core create #13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: move python public API to djc-core create #13
Conversation
| ValueError: If the HTML is malformed or cannot be parsed. | ||
| """ | ||
| ... | ||
| from djc_core.djc_html_transformer import * |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Rust->Python bindings by maturin / PyO3 don't generate typings, so a __init__.pyi file is needed so that Mypy, Pyright, etc, are able to know what API the final package exposes.
To keep it clean, each Rust crate has it's own .pyi file, and then this __init__.pyi brings it all together.
| /// A Result containing either: | ||
| /// - Ok((html, captured)): A tuple with the transformed HTML and captured attributes | ||
| /// - Err(error): An error if the HTML is malformed or cannot be parsed. | ||
| pub fn set_html_attributes( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously the djc-html-transformer crate contained PyO3 code (which is used for defining the Python bindings).
To make sense of the code and keep it clean, I adopted following approach:
- Each crate (AKA Rust package) has
lib.rs(which is like Python's__init__.py). These files do not define the main logic, but only the public API of the create. So the API that's to be used by other crates. - The
djc-corecrate imports other crates - And it is only this
djc-corewhere we define the Python API using PyO3.
So it's hard to see in this diff (would be easier if you check the raw file), but this file now practically only re-exports transform() function as set_html_attributes().
And it is in djc_core/src/lib.rs where we import this set_html_attributes() and re-export it as Python API.
| @@ -0,0 +1,406 @@ | |||
| use quick_xml::events::{BytesStart, Event}; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not new, this was previously in djc-html-transformer/src/lib.rs. Just removed definition of the Python API from here.
| #[pyo3( | ||
| text_signature = "(html, root_attributes, all_attributes, *, check_end_names=False, watch_on_attribute=None)" | ||
| )] | ||
| pub fn set_html_attributes( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here is the Python definition of set_html_attributes() function.
To actually expose it to Python, this Python function is added to the module's scope on line 12:
m.add_function(wrap_pyfunction!(set_html_attributes, m)?)?;|
cc @EmilStenstrom, just plain refactor, but comments here go over how the Rust crates are laid out. |
Just refactor so that the next PR contains only code related to the Django template AST parser.