Pvlib-python: pvlib v 0.6.0.2 TypeError: ineichen() got an unexpected keyword argument 'solar_postion'

[itprorh66]

In using the location.get_clearsky method with calling parameters (times, model='ineichen', solar_postion= solpos, dni_extra=None).

When executing the statement at line 219 which reads:
cs = clearsky.ineichen(apparent_zenith, airmass_absolute,
linke_turbidity, altitude=self.altitude,
dni_extra=dni_extra, **kwargs)
the error: TypeError: ineichen() got an unexpected keyword argument 'solar_postion' is produced.

I believe this error is the result of the fact the called function, located at clearsky.py line 18, does not include the **kwargs attribute.

In earlier versions of pvlib, the statement at line 219 of location.py was as shown below:
cs = clearsky.ineichen(apparent_zenith, airmass_absolute,
linke_turbidity, altitude=self.altitude,
dni_extra=dni_extra)

Versions:

• pvlib.__version__: 0.6.02

[cwhanse]

solar_postion is misspelled here, perhaps in your code also?

[itprorh66]

Cliff,

Thanks for the quick response.  Yes, I totally missed that solar_position was misspelled.   That resolved the issue.  The funny thing, is the previous version  didn't throw an error, so I immediately went to the updated code.  My bad.

Please close the bug report.
On 2/14/2019 3:08:46 PM, Cliff Hansen [e-mail] wrote:
solar_postion is misspelled here, perhaps in your code also?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub [https://github.com/pvlib/pvlib-python/issues/660#issuecomment-463774606], or mute the thread [https://github.com/notifications/unsubscribe-auth/AGb9WHmbSY1ZKldmRD6F30UZ8dKLVBIeks5vNcJNgaJpZM4a8VWw].

[markcampanelli]

@itprorh66 That’s interesting and seems to suggest that using **kwargs in a function signature can let bugs in user code slip through more easily. Is that a proper understanding here?

[itprorh66]

Mark,

Not sure about the generality of the situation, but can say in this instance, I have been working with pvlib for about 6 to 8 months, and have had this code error present for the majority of that time without ever receiving the error message.  

Bob

On 2/14/2019 7:35:58 PM, Mark Campanelli [e-mail] wrote:
@itprorh66 [https://github.com/itprorh66] That’s interesting and seems to suggest that using **kwargs in a function signature can let bugs in user code slip through more easily. Is that a proper understanding here?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [https://github.com/pvlib/pvlib-python/issues/660#issuecomment-463860544], or mute the thread [https://github.com/notifications/unsubscribe-auth/AGb9WE0TE4c-DcDfzdk1LUW9J1eZ8EWRks5vNgDugaJpZM4a8VWw].

[mikofski]

@markcampanelli afaik using *args and **kwargs isn't recommend. Although I do it all the time, both pylint and pyflakes complain when I do. As the tao of Python says, "explicit is better than implicit." Oh well, live and learn. FYI: I meant this comment as agreement, not criticism. Sorry!

[wholmgren]

Yes, I try to avoid *args and **kwargs because they can mask errors like this one. In this situation, I used **kwargs because I thought it was silly to explicitly name all of the ineichen and simplified_solis kwargs in Location.get_clearsky. I'll appeal to the tao of Python with "explicit is better than implicit... although practicality beats purity"!

I suspect that PR #459 caused the user code to break, but that was released several versions ago (0.6.0).

[cwhanse]

@itprorh66 in this case the error only cost code performance (re-computing solar position). I don't think it had any other effect.

[markcampanelli]

Thanks all for the discussion. I just recently had the temptation to add **kwargs to make an interface more “flexible”, but now I see that my particular use case doesn’t warrant this type of trade off.

(I’ve been trying a Python3 function design pattern that always uses required/optional keyword arguments and always returns a single dictionary (possibly with nested dictionaries). The driving API use case is where a sub-dictionary of fit parameters from the result = fit(...) function call can be passed succinctly and accurately to the “forward” model function using something like i_at_v(V_V=V_V, **result['model_params_fit']), where the currents themselves are retrieved directly with the function call as i_at_v(V_V=V_V, **result['model_params_fit'])['I_A'].)