Closed MichaReiser closed 1 year ago
I feel a bit awkward to put format functions to parser directory. But that will be fine if it helps to maintaining Ruff in practice. rustpython-common has too many dependencies to handling platform/threading stuff. To make future contributors not being confused, could you add comments to format.rs and cformat.rs that it doesn't look like parser component but added to support common parser user scenario?
I feel a bit awkward to put format functions to parser directory. But that will be fine if it helps to maintaining Ruff in practice. rustpython-common has too many dependencies to handling platform/threading stuff. To make future contributors not being confused, could you add comments to format.rs and cformat.rs that it doesn't look like parser component but added to support common parser user scenario?
I understand. Would it help if we move the logic into a new rustpython-format
crate?
Either way will be good to me.
I added a new crate and updated the repository URLs.
Thank you!
This PR moves the
format
andcformat
modules fromRustPython
into the newformat
crate. I'm not sure if this is the right crate to add. Please let me know if I should move it to another crate and/or add it behind a feature flag.The
format
implementation has an optimized path forBorrowedStr
. I kept that path by introducing a newCharLen
trait thatBorrowedStr
can implement inRustPython
.The goal of this is that
format
andcformat
are the last two modules fromRustPython
that ruff depends on. Moving them into this repository would allow us to cut that dependency.