Modernizing pvlib - namely: polars & type hints?

[PhilBrk8]

Given the performance advantages, what is the take here to co-using / transitioning to polars?

@kandersolar wrote me a looong time ago, that he is in favour of bringing up pvlib to a more modern version of python.
I wanted to do this my project, but as life goes, stuff comes into the way regularly.

Refractoring functions to use polars was one of my intensions.
I also intended to incorporate type hints since I am also a fierce devote to typescript >> javascript cult (but we don't want to talk more about this in python-land)
Cross-referencing @kandersolar comment.

[echedey-ls]

Relevant context:

• Cython Implementation of the NREL SPA #1906
• Replacing pandas with polars #1926

co-using

+1

[kandersolar]

See also

• Type hints in pvlib functional code #2062

[kandersolar]

re polars, my view is still what I expressed in #1926:

• removing support for pandas inputs is too big a break to be seriously considered, IMHO
• supporting both pandas and polars could be considered, but that discussion would need to be informed by someone putting in the exploratory work to better understand the benefits (speed? convenience?) and costs (code complexity? can we support polars without making it a required dependency?) first.

type hints: let's keep that discussion in #2062

[markcampanelli]

I’m not sure how practical this would be to realize, but the “numeric” type could become a pvlib-defined interface (perhaps a Python Protocol?), which float, numpy.ndarray, pandas.Series, pandas.Dataframe, and polars.foobar (?) all implement. Likewise, any future additions need only satisfy the interface (with the caveat below). All of the interface implementations can be added, multiplied, etc., which is their common interface. However, probably not all numpy/scipy library functions could be expected to support all types that implement the interface, so there would still likely be messy type checking/conversion in some computations. It’s also less clear to me how to optionally handle the pandas (and polars?) indexes in said interface, and possibly even more daunting is the combinatoric growth of various type combinations in computations. (I think I raised the question before about making formal rules on what an output type should be for various combinations of input types, but I suppose that in this case the output would be the same “numeric” interface type.) TBH, this sounds like the type of problem that the whole Scientific Python community should address, which could greatly increase and ease interoperability between libraries. Mark Campanelli LinkedIn <https://www.linkedin.com/in/markcampanelli/> Intelligent Measurement Systems LLC <https://intelligentmeasurementsystems.com> Try PVfit <https://pvfit.app> today!

…

On Wed, Jul 24, 2024 at 06:15 Kevin Anderson ***@***.***> wrote: re polars, my view is still what I expressed in #1926 <#1926>: - removing support for pandas inputs is too big a break to be seriously considered, IMHO - supporting both pandas and polars could be considered, but that discussion would need to be informed by someone putting in the exploratory work to better understand the benefits (speed? convenience?) and costs (code complexity? can we support polars without making it a required dependency?) first. type hints: let's keep that discussion in #2062 <#2062> — Reply to this email directly, view it on GitHub <#2144 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAISX46RNR3JJLCPVPE5F7DZN6LG5AVCNFSM6AAAAABLMBPIN2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJTG4YDSMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>