Georg Brandl

Regardless of if this instance can be fixed, relying on destructors being called at program exit is a recipe for sadness when Python is involved.

> For example, the [`missing_const_for_fn` lint](https://rust-lang.github.io/rust-clippy/master/index.html#/missing_const_for_fn) is explicitly in development and has a bunch of caveats. Especially since what could be `const` today may not be able to be `const`...

> Did i do somethings wrong or it due to the pyo3 implementation ? ty Keep in mind that the `Vec`s you pass in and out of the function have...

Maybe need to use https://docs.rs/rust_decimal/latest/rust_decimal/struct.Decimal.html#method.from_scientific instead?

> I started working on a draft of this in #2367, however I haven't found the time to continue with this. Help in design or implementation is always welcome. As...

At least `num-bigint` is already supported (as is `num-complex`), as an optional feature: https://docs.rs/pyo3/latest/pyo3/#optional-feature-flags `num-rational` could be implemented very similarly.

IMO the current mode (with the warning elevated to error) is fine. With arguments that can be `None`, it's pretty typical that they also have a default of `None`.

> I'm generally against doing implicit things, so this sounds good. Although "implicit" can mean a lot of different things. In this case, you could argue that any case of...

I'm not against changing the default, as long as any change in behavior is clearly visible with new compile errors. Please don't add "unstable" to the feature name, the API...

Does this fix #780 ? (It was closed by the submitter, not fixed.)