Test bug: rs and rsh swapped in `test_sde.py`

[vfilter]

Describe the bug
In the test__fit_sandia_cocontent() unit test, we are unpacking the return values like so:

iph, io, rsh, rs, n = sde._fit_sandia_cocontent(v, i, nsvth)

However, the _fit_sandia_cocontent function returns values in this order

return iph, io, rs, rsh, n

Interestingly the test still passes, but this is likely because the values themselves in the fixture are swapped: -.232, -.2596

To Reproduce
Steps to reproduce the behavior:

1. Manually confirm unit test of _fit_sandia_cocontent vs actual implementation

Expected behavior
Order should be correct and fixtures should be unswapped.

[markcampanelli]

Ordering is an often missed source of code complexity. This is why I greatly prefer using all named function arguments (which allows passing of unpacked argument dictionaries with no care of order) and single-dictionary return values. Thus, across input and output everything is always name identified and order doesn't matter. A downside here might be neatly typing the output dictionary elements.

[cwhanse]

Thanks for reporting @vfilter curious how you found this one :)

Confirmed bug, effect is limited to the test. The test result is still valid since the order of arguments and expected values still match.

[markcampanelli]

Ordering is an often missed source of code complexity. This is why I greatly prefer using all named function arguments (which allows passing of unpacked argument dictionaries with no care of order) and single-dictionary return values. Thus, across input and output everything is always name identified and order doesn't matter. A downside here might be neatly typing the output dictionary elements.

Here are three typed-dictionary techniques that only use the standard library. I have my preference, but have used all three patterns successfully: https://youtu.be/GCagRSaH8lg

Pydantic would be an obvious alternative to @DataClass, allowing more flexible validation (but you have to maintain that validation, kinda like a representative democracy). See https://youtu.be/zN4VCb0LbQI

[vfilter]

@cwhanse I'm reimplementing pvlib in Rust, so as a consequence I'm poking through the whole codebase and stumble across these oddities.

[markcampanelli]

@vfilter OMG I could (metaphorically) kiss you! Is this an open source project?

[vfilter]

@markcampanelli it is not at this point. I want to make sure to reach test parity (to the best degree possible, given some of the architectural differences) with upstream pvlib-python first and then release. Probably some time Q1 2026.

Our use-case requires massive scalability with hundreds of thousands of sites simulated daily, so I am betting on speedup through rayon parallelization and using polars as the dataframe backend, which comes with great SIMD support besides imo being the better library. For example, many of the low-level pvlib kernels can be reproduced using polars expressions, making things fast.

Down the line, having Python bindings through pyo3 might also be on the table, but I'm far away from that. Modelchain already works, but it's a pretty manual, painstaking process. Frankly, if it wasn't for the incredible in-line documentation created by this fantastic community, I don't think this would be possible.

[markcampanelli]

@vfilter My project would have similar gains from speedups, and could also use production-level code safety. Lmk if you'd consider a beta user, with some potential for contribution. Happy to sign an NDA.