The pyo3_built macro adds an import bound for email.utils to parse a string date into a datetime, which seems really unnecessary to me. It adds a significant amount of import time to our library.
($py: ident, $info: ident, $dict: ident, "time") => {
let dt = $py
.import_bound("email.utils")?
.call_method1("parsedate_to_datetime", ($info::BUILT_TIME_UTC,))?;
$dict.set_item("info-time", dt)?;
};
Even parsing the date in Rust and importing datetime to generate a Datetime object directly (while significantly better) seems unnecessary, although that would be a backwards-compatible.
My suggestion would be to replace the info-time field with a ISO 8601 timestamp string that we generate on the Rust side. Then if a user really wants a Datetime they can just datetime.datetime.fromisoformat the string.
The
pyo3_builtmacro adds an import bound foremail.utilsto parse a string date into a datetime, which seems really unnecessary to me. It adds a significant amount of import time to our library.Even parsing the date in Rust and importing
datetimeto generate aDatetimeobject directly (while significantly better) seems unnecessary, although that would be a backwards-compatible.My suggestion would be to replace the
info-timefield with a ISO 8601 timestamp string that we generate on the Rust side. Then if a user really wants aDatetimethey can justdatetime.datetime.fromisoformatthe string.